میں پچھلے کئی سالوں سے ایک رجحان دیکھنے کے لیے کافی عرصے سے فرنٹ اینڈ ڈیولپمنٹ میں رہا ہوں: نوجوان ڈویلپرز پروگرامنگ کے ایک نئے نمونے کے ساتھ اس کے تاریخی تناظر کو سمجھے بغیر کام کر رہے ہیں۔ یقیناً کسی چیز کو نہ جاننا بالکل قابل فہم ہے۔ ویب ایک بہت بڑی جگہ ہے جس میں مہارتوں اور خصوصیات کے متنوع سیٹ ہیں، اور ہم ہمیشہ وہ نہیں جانتے جو ہم نہیں جانتے۔ اس میدان میں سیکھنا ایک جاری سفر ہے بجائے اس کے کہ ایک بار ہوتا ہے اور ختم ہوتا ہے۔ مثال کے طور پر: میری ٹیم میں سے کسی نے پوچھا کہ کیا یہ بتانا ممکن ہے کہ کیا صارف UI میں کسی خاص ٹیب سے دور جاتے ہیں۔ میں نے جاوا اسکرپٹ کے ان لوڈ ایونٹ سے پہلے نشاندہی کی۔ لیکن جن لوگوں نے اس سے پہلے اس سے نمٹا ہے وہ جانتے ہیں کہ یہ ممکن ہے کیونکہ انہیں دوسری سائٹوں پر غیر محفوظ شدہ ڈیٹا کے بارے میں انتباہات کا سامنا کرنا پڑا ہے، جس کے لیے پہلے سے لوڈ کرنا ایک عام استعمال کا معاملہ ہے۔ میں نے اچھی پیمائش کے لیے اپنے ساتھی کو صفحہ چھپائیں اور مرئیت کی تبدیلی کے واقعات کی نشاندہی بھی کی۔ مجھے اس کے بارے میں کیسے پتہ چلا؟ کیونکہ یہ کسی اور پروجیکٹ میں سامنے آیا، اس لیے نہیں کہ میں نے ابتدائی طور پر جاوا اسکرپٹ سیکھتے وقت اس پر مطالعہ کیا۔ حقیقت یہ ہے کہ جدید فرنٹ اینڈ فریم ورک ٹیکنالوجی کے جنات کے کندھوں پر کھڑے ہیں جو ان سے پہلے تھے۔ وہ ترقی کے طریقوں کا خلاصہ کرتے ہیں، اکثر بہتر ڈویلپر کے تجربے کے لیے جو کہ کم کر دیتا ہے، یا اسے ختم کر دیتا ہے، یہ جاننے یا چھونے کی ضرورت ہے کہ روایتی طور پر سامنے کے آخر میں کیا ضروری تصورات ہیں جو شاید ہر ایک کو جاننا چاہیے۔ CSS آبجیکٹ ماڈل (CSSOM) پر غور کریں۔ آپ توقع کر سکتے ہیں کہ CSS اور JavaScript میں کام کرنے والے کسی بھی شخص کے پاس CSSOM کا تجربہ ہے، لیکن ایسا ہمیشہ نہیں ہوتا ہے۔ ایک ای کامرس سائٹ کے لیے ایک React پروجیکٹ تھا جس پر میں نے کام کیا تھا جہاں ہمیں فی الحال منتخب ادائیگی فراہم کنندہ کے لیے اسٹائل شیٹ لوڈ کرنے کی ضرورت تھی۔ مسئلہ یہ تھا کہ اسٹائل شیٹ ہر صفحے پر لوڈ ہو رہی تھی جب اس کی صرف ایک مخصوص صفحہ پر ضرورت تھی۔ ڈیولپر کو ایسا کرنے کی ذمہ داری سونپی گئی ہے اس نے کبھی بھی اسٹائل شیٹ کو متحرک طور پر لوڈ نہیں کیا تھا۔ ایک بار پھر، یہ مکمل طور پر قابل فہم ہے جب React روایتی نقطہ نظر کو ختم کرتا ہے جس تک آپ پہنچ چکے ہیں۔ CSSOM ممکنہ طور پر ایسی چیز نہیں ہے جس کی آپ کو اپنے روزمرہ کے کام میں ضرورت ہو۔ لیکن امکان ہے کہ آپ کو کسی موقع پر اس کے ساتھ بات چیت کرنے کی ضرورت پڑے گی، یہاں تک کہ ایک دفعہ میں بھی۔ ان تجربات نے مجھے یہ مضمون لکھنے کی ترغیب دی۔ جنگل میں بہت سی موجودہ ویب خصوصیات اور ٹیکنالوجیز ہیں جنہیں آپ اپنے روزمرہ کے کام میں براہ راست کبھی نہیں چھو سکتے ہیں۔ شاید آپ ویب ڈویلپمنٹ کے لیے بالکل نئے ہیں اور ان سے بالکل ناواقف ہیں کیونکہ آپ ایک مخصوص فریم ورک کے تجرید میں پھنسے ہوئے ہیں جس کے لیے آپ کو اسے گہرائی سے جاننے کی ضرورت نہیں ہے، یا بالکل بھی۔ میں خاص طور پر XML کے بارے میں بات کر رہا ہوں، جسے ہم میں سے بہت سے لوگ جانتے ہیں کہ ایک قدیم زبان ہے جو HTML سے بالکل مختلف نہیں ہے۔ میں اسے حالیہ WHATWG مباحثوں کی وجہ سے پیش کر رہا ہوں جو تجویز کرتا ہے کہ XML اسٹیک کا ایک اہم حصہ جسے XSLT پروگرامنگ کہا جاتا ہے براؤزرز سے ہٹا دیا جانا چاہئے۔ یہ بالکل اسی طرح کی پرانی، موجودہ ٹیکنالوجی ہے جو ہمارے پاس برسوں سے موجود ہے جسے کسی ایسی عملی چیز کے لیے استعمال کیا جا سکتا ہے جیسا کہ CSSOM کی صورتحال میں میری ٹیم تھی۔ کیا آپ نے پہلے XSLT کے ساتھ کام کیا ہے؟ آئیے دیکھتے ہیں کہ کیا ہم اس پرانی ٹیکنالوجی کی طرف بہت زیادہ جھکاؤ رکھتے ہیں اور آج حقیقی دنیا کے مسائل سے نمٹنے کے لیے XML کے سیاق و سباق سے باہر اس کی خصوصیات کا فائدہ اٹھاتے ہیں۔ XPath: مرکزی API سب سے اہم XML ٹکنالوجی جو شاید سیدھے XML نقطہ نظر سے باہر سب سے زیادہ مفید ہے XPath ہے، ایک استفسار کی زبان جو آپ کو ایک جڑ عنصر کے ساتھ مارک اپ ٹری میں کوئی نوڈ یا وصف تلاش کرنے کی اجازت دیتی ہے۔ مجھے XSLT سے ذاتی لگاؤ ہے، لیکن یہ XPath پر بھی انحصار کرتا ہے، اور ذاتی پیار کو درجہ بندی کی اہمیت میں ایک طرف رکھنا چاہیے۔ XSLT کو ہٹانے کی دلیل میں XPath کا کوئی ذکر نہیں ہے، لہذا میرا خیال ہے کہ اس کی اب بھی اجازت ہے۔ یہ اچھی بات ہے کیونکہ XPath ٹیکنالوجیز کے اس مجموعہ میں مرکزی اور سب سے اہم API ہے، خاص طور پر جب عام XML استعمال سے باہر استعمال کرنے کے لیے کچھ تلاش کرنے کی کوشش کی جائے۔ یہ اہم ہے کیونکہ، اگرچہ CSS سلیکٹرز کو آپ کے صفحہ میں زیادہ تر عناصر تلاش کرنے کے لیے استعمال کیا جا سکتا ہے، لیکن وہ ان سب کو تلاش نہیں کر سکتے۔ مزید برآں، DOM میں اس کی موجودہ پوزیشن کی بنیاد پر کسی عنصر کو تلاش کرنے کے لیے CSS سلیکٹرز کا استعمال نہیں کیا جا سکتا۔ XPath کر سکتے ہیں۔ اب، آپ میں سے کچھ اسے پڑھ رہے ہیں شاید XPath جانتے ہوں، اور کچھ نہ جانتے ہوں۔ XPath ٹیکنالوجی کا ایک بہت بڑا شعبہ ہے، اور میں واقعی تمام بنیادی باتیں نہیں سکھا سکتا اور اس طرح کے ایک مضمون میں آپ کو اس کے ساتھ کرنے کے لیے بہترین چیزیں بھی نہیں دکھا سکتا۔ میں نے اصل میں وہ مضمون لکھنے کی کوشش کی، لیکن اوسط Smashing Magazine کی اشاعت 5,000 الفاظ سے زیادہ نہیں ہوتی۔ میں پہلے ہی اس سے زیادہ پر تھا۔2,000 الفاظ جبکہ بنیادی باتوں سے صرف آدھے راستے پر۔ لہذا، میں XPath کے ساتھ عمدہ چیزیں کرنا شروع کرنے جا رہا ہوں اور آپ کو کچھ لنکس دینے جا رہا ہوں جو آپ بنیادی باتوں کے لیے استعمال کر سکتے ہیں اگر آپ کو یہ چیزیں دلچسپ لگیں۔ XPath اور CSS کا امتزاج XPath بہت سی چیزیں کر سکتا ہے جو CSS سلیکٹرز عناصر سے استفسار کرتے وقت نہیں کر سکتے۔ لیکن CSS سلیکٹرز کچھ چیزیں بھی کر سکتے ہیں جو XPath نہیں کر سکتے، یعنی کلاس کے نام سے عناصر کو استفسار کرتے ہیں۔
سی ایس ایس ایکس پاتھ .myClass /*[contains(@class, "myClass")]
اس مثال میں، CSS ایسے عناصر سے استفسار کرتا ہے جن میں .myClass کلاس نام ہوتا ہے۔ دریں اثنا، XPath مثال ایسے عناصر سے استفسار کرتی ہے جن میں سٹرنگ "myClass" کے ساتھ انتساب کی کلاس ہوتی ہے۔ دوسرے الفاظ میں، یہ کسی بھی وصف میں myClass والے عناصر کا انتخاب کرتا ہے، بشمول .myClass کلاس نام والے عناصر — نیز سٹرنگ میں "myClass" والے عناصر، جیسے .myClass2۔ XPath اس لحاظ سے وسیع تر ہے۔ تو، نہیں. میں یہ تجویز نہیں کر رہا ہوں کہ ہمیں CSS کو ٹاس کرنا چاہیے اور XPath کے ذریعے تمام عناصر کو منتخب کرنا شروع کرنا چاہیے۔ یہ بات نہیں ہے۔ نقطہ یہ ہے کہ XPath ایسی چیزیں کر سکتا ہے جو CSS نہیں کر سکتا اور اب بھی بہت مفید ہو سکتا ہے، حالانکہ یہ براؤزر اسٹیک میں ایک پرانی ٹیکنالوجی ہے اور پہلی نظر میں واضح نہیں لگ سکتی ہے۔ آئیے دونوں ٹیکنالوجیز کو ایک ساتھ استعمال کریں نہ صرف اس لیے کہ ہم کر سکتے ہیں، بلکہ اس لیے کہ ہم اس عمل میں XPath کے بارے میں کچھ سیکھیں گے، اسے آپ کے اسٹیک میں ایک اور ٹول بنا دیں گے — جس کے بارے میں آپ کو معلوم نہیں ہو گا کہ وہ پہلے ہی موجود ہے! مسئلہ یہ ہے کہ JavaScript کا document.evaluate طریقہ اور مختلف سوالات سلیکٹر کے طریقے جو ہم JavaScript کے لیے CSS APIs کے ساتھ استعمال کرتے ہیں مطابقت نہیں رکھتے۔ میں نے ہمیں شروع کرنے کے لیے ایک ہم آہنگ استفسار کرنے والا API بنایا ہے، اگرچہ اعتراف کے طور پر، میں نے اس میں بہت زیادہ غور نہیں کیا ہے کیونکہ یہ ہمارے یہاں جو کچھ کر رہے ہیں اس سے الگ ہے۔ دوبارہ قابل استعمال استفسار کنسٹرکٹر کی ایک کافی آسان کام کرنے والی مثال یہ ہے: برائن راسموسن کا قلمی سوال ایکس پاتھ [فورکڈ] دیکھیں۔ میں نے دستاویز آبجیکٹ پر دو طریقے شامل کیے ہیں: queryCSSSelectors (جو کہ بنیادی طور پر querySelectorAll ہے) اور queryXPaths۔ یہ دونوں ایک queryResults آبجیکٹ واپس کرتے ہیں:
{ سوال کی قسم: نوڈس | تار | نمبر | بولین نتائج: کوئی بھی [] // html عناصر، xml عناصر، تار، نمبر، بولین، queryCSSSelectors: (استفسار: سٹرنگ، ترمیم: بولین) => سوال کے نتائج، queryXpaths: (استفسار: سٹرنگ، ترمیم: بولین) => سوال کے نتائج }
queryCSSSelectors اور queryXpaths فنکشنز وہ استفسار چلاتے ہیں جو آپ انہیں نتائج کی صف میں موجود عناصر پر دیتے ہیں، جب تک کہ نتائج کی سرنی بالکل نوڈس کی ہو۔ دوسری صورت میں، یہ ایک خالی صف اور نوڈس کی ایک قسم کے ساتھ ایک سوال کا نتیجہ واپس کر دے گا۔ اگر ترمیم کی خاصیت درست پر سیٹ کی جاتی ہے، تو فنکشنز اپنے سوالات کے نتائج کو تبدیل کر دیں گے۔ کسی بھی حالت میں اسے پیداواری ماحول میں استعمال نہیں کیا جانا چاہیے۔ میں یہ کام خالصتاً دو استفسار APIs کو ایک ساتھ استعمال کرنے کے مختلف اثرات کو ظاہر کرنے کے لیے کر رہا ہوں۔ مثال کے سوالات میں مختلف XPath سوالات کی چند مثالیں دکھانا چاہتا ہوں جو کچھ طاقتور چیزوں کو ظاہر کرتی ہیں جو وہ کر سکتے ہیں اور انہیں دوسرے طریقوں کی جگہ کیسے استعمال کیا جا سکتا ہے۔ پہلی مثال ہے //li/text()۔ یہ تمام li عناصر سے استفسار کرتا ہے اور ان کے ٹیکسٹ نوڈس کو واپس کرتا ہے۔ لہذا، اگر ہم درج ذیل ایچ ٹی ایم ایل سے استفسار کریں:
- ایک
- دو
- تین
…یہ وہی ہے جو واپس کیا جاتا ہے:
{"queryType":"xpathEvaluate","نتائج":["one","دو","تین"],"resultType":"string"}
دوسرے الفاظ میں، ہمیں مندرجہ ذیل صف ملتی ہے: ["ایک","دو"،"تین"]۔ عام طور پر، آپ اسے حاصل کرنے کے لیے li عناصر کے لیے استفسار کریں گے، اس استفسار کے نتیجے کو ایک صف میں تبدیل کریں گے، صف کا نقشہ بنائیں گے، اور ہر عنصر کا متنی نوڈ واپس کریں گے۔ لیکن ہم اسے XPath کے ساتھ زیادہ اختصار کے ساتھ کر سکتے ہیں: document.queryXPaths("//li/text()") نتائج۔
نوٹ کریں کہ ٹیکسٹ نوڈ حاصل کرنے کا طریقہ ٹیکسٹ() کا استعمال کرنا ہے، جو فنکشن کے دستخط کی طرح لگتا ہے - اور یہ ہے۔ یہ ایک عنصر کا ٹیکسٹ نوڈ لوٹاتا ہے۔ ہماری مثال میں، مارک اپ میں تین li عناصر ہیں، ہر ایک متن پر مشتمل ہے ("ایک"، "دو"، اور "تین")۔
آئیے ٹیکسٹ() استفسار کی ایک اور مثال دیکھیں۔ فرض کریں کہ یہ ہمارا مارک اپ ہے:
آئیے ایک استفسار لکھتے ہیں جو href وصف کی قدر لوٹاتا ہے: document.queryXPaths("//a[text() = 'سائن ان']/@href").نتائج۔
یہ موجودہ دستاویز پر ایک XPath استفسار ہے، بالکل پچھلی مثال کی طرح، لیکن اس بار ہم ایک لنک (ایک عنصر) کا href وصف واپس کرتے ہیں جس میں متن "سائن ان" ہے۔ اصل واپس آگیانتیجہ ہے ["/login.html"]۔ XPath افعال کا جائزہ XPath کے متعدد فنکشنز ہیں، اور آپ شاید ان سے ناواقف ہیں۔ میرے خیال میں بہت سے ایسے ہیں جن کے بارے میں جاننے کے قابل ہیں، جن میں درج ذیل شامل ہیں:
starts-withاگر کوئی متن کسی خاص دوسرے متن کی مثال کے ساتھ شروع ہوتا ہے، starts-with(@href, 'http:') درست ہوتا ہے اگر ایک href وصف http: سے شروع ہوتا ہے۔ پر مشتمل ہے اگر کسی متن میں کسی خاص دوسرے متن کی مثال شامل ہو، contains(text(), "Smashing Magazine") درست ہو جاتا ہے اگر کسی ٹیکسٹ نوڈ میں کہیں بھی "Smashing Magazine" کے الفاظ شامل ہوں۔ شمار اس بات کی گنتی لوٹاتا ہے کہ ایک سوال کے کتنے میچ ہیں۔ مثال کے طور پر، count(//*[starts-with(@href, 'http:']) اس بات کی گنتی لوٹاتا ہے کہ سیاق و سباق کے نوڈ میں کتنے لنکس میں ایک href وصف کے ساتھ عناصر ہیں جو HTTP: سے شروع ہونے والے متن پر مشتمل ہے۔ substring جاوا اسکرپٹ سبسٹرنگ کی طرح کام کرتا ہے، سوائے اس کے کہ آپ سٹرنگ کو دلیل کے طور پر پاس کریں۔ مثال کے طور پر، substring("my text", 2, 4) "y t" لوٹاتا ہے۔ substring-before کسی سٹرنگ کا حصہ دوسری سٹرنگ سے پہلے لوٹاتا ہے۔ مثال کے طور پر، substing-before("my text", "") "my" لوٹاتا ہے۔ اسی طرح، substring-before("hi","bye") ایک خالی سٹرنگ لوٹاتا ہے۔ substring-afterدوسری سٹرنگ کے بعد سٹرنگ کا حصہ واپس کرتا ہے۔ مثال کے طور پر، substing-after("my text"، "") "text" لوٹاتا ہے۔ اسی طرح، substring-after("hi","bye") ایک خالی سٹرنگ لوٹاتا ہے۔ نارملائز-اسپیس آرگیومینٹ اسٹرنگ کو وائٹ اسپیس کے ساتھ واپس کرتا ہے جس میں لیڈنگ اور ٹریلنگ وائٹ اسپیس کو سٹرپ کرکے اور وائٹ اسپیس حروف کی ترتیب کو ایک اسپیس سے تبدیل کرکے نارملائز کیا جاتا ہے۔ not ایک بولین سچ لوٹاتا ہے اگر دلیل غلط ہے، ورنہ غلط۔ سچ بولین سچ کو لوٹاتا ہے۔ جھوٹ بولین غلط واپس کرتا ہے۔ concat وہی چیز جو جاوا اسکرپٹ کونکیٹ کی طرح ہے، سوائے اس کے کہ آپ اسے سٹرنگ پر ایک طریقہ کے طور پر نہیں چلائیں۔ اس کے بجائے، آپ ان تمام تاروں کو ڈالتے ہیں جنہیں آپ جوڑنا چاہتے ہیں۔ string-lengthیہ JavaScript string-length جیسی نہیں ہے، بلکہ اسٹرنگ کی لمبائی لوٹاتا ہے جو اسے بطور دلیل دی گئی ہے۔ translateThis ایک سٹرنگ لیتا ہے اور دوسری دلیل کو تیسری دلیل میں تبدیل کرتا ہے۔ مثال کے طور پر، ترجمہ("abcdef", "abc", "XYZ") XYZdef کو آؤٹ پٹ کرتا ہے۔
ان مخصوص XPath فنکشنز کے علاوہ، بہت سے دوسرے فنکشنز ہیں جو اپنے JavaScript ہم منصبوں کی طرح کام کرتے ہیں — یا بنیادی طور پر کسی بھی پروگرامنگ لینگویج میں ہم منصب — جو شاید آپ کو بھی کارآمد معلوم ہوں گے، جیسے کہ فرش، چھت، گول، رقم وغیرہ۔ مندرجہ ذیل ڈیمو ان افعال میں سے ہر ایک کی وضاحت کرتا ہے: Bryan Rasmussen کی طرف سے Pen XPath عددی افعال [فورکڈ] دیکھیں۔ نوٹ کریں کہ، زیادہ تر سٹرنگ ہیرا پھیری کے افعال کی طرح، بہت سے عددی ایک ہی ان پٹ لیتے ہیں۔ یہ یقیناً ہے، کیونکہ سمجھا جاتا ہے کہ وہ استفسار کے لیے استعمال کیے جائیں گے، جیسا کہ آخری XPath مثال میں: //li[floor(text()) > 250]/@val
اگر آپ ان کا استعمال کرتے ہیں، جیسا کہ زیادہ تر مثالیں کرتے ہیں، تو آپ اسے پہلے نوڈ پر چلائیں گے جو راستے سے میل کھاتا ہے۔ کچھ قسم کے تبادلوں کے فنکشنز بھی ہیں جن سے آپ کو شاید بچنا چاہیے کیونکہ JavaScript میں پہلے سے ہی اپنی قسم کی تبدیلی کے مسائل ہیں۔ لیکن ایسے وقت بھی ہو سکتے ہیں جب آپ کسی تار کو کسی نمبر میں تبدیل کرنا چاہتے ہیں تاکہ اسے کسی دوسرے نمبر کے مقابلے میں چیک کیا جا سکے۔ فنکشن جو کسی چیز کی قسم کو متعین کرتے ہیں وہ ہیں بولین، نمبر، سٹرنگ اور نوڈ۔ یہ اہم XPath ڈیٹا ٹائپس ہیں۔ اور جیسا کہ آپ تصور کر سکتے ہیں، ان میں سے زیادہ تر فنکشنز ڈیٹا ٹائپ پر استعمال کیے جا سکتے ہیں جو DOM نوڈس نہیں ہیں۔ مثال کے طور پر، substring-after ایک سٹرنگ لیتا ہے جیسا کہ ہم پہلے ہی کور کر چکے ہیں، لیکن یہ ایک href انتساب کی سٹرنگ ہو سکتی ہے۔ یہ صرف ایک تار بھی ہوسکتا ہے:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
ظاہر ہے، یہ مثال ہمیں نتائج کی صف کو ["world"] کے طور پر واپس دے گی۔ اسے عملی طور پر دکھانے کے لیے، میں نے ان چیزوں کے خلاف فنکشنز کا استعمال کرتے ہوئے ایک ڈیمو صفحہ بنایا ہے جو DOM نوڈس نہیں ہیں: برائن راسموسن کا قلمی سوال ایکس پاتھ [فورکڈ] دیکھیں۔ آپ کو ٹرانسلیٹ فنکشن کے حیران کن پہلو کو نوٹ کرنا چاہیے، جو یہ ہے کہ اگر آپ کے پاس دوسری دلیل میں کوئی کردار ہے (یعنی حروف کی فہرست جس کا آپ ترجمہ کرنا چاہتے ہیں) اور ترجمہ کرنے کے لیے کوئی مماثل حرف نہیں ہے، تو وہ حرف آؤٹ پٹ سے ہٹا دیا جائے گا۔ اس طرح، یہ:
ترجمہ ('ہیلو، میرا نام انیگو مونٹویا ہے، آپ نے میرے والد کو مار ڈالا، مرنے کی تیاری کریں','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…نتائج سٹرنگ میں، بشمول خالی جگہیں: ["*****"]
اس کا مطلب یہ ہے کہ حرف "a" کا ترجمہ ستارے (*) میں کیا جا رہا ہے، لیکن ہر دوسرا حرف جس کا ترجمہ نہیں ہے، ہدف کے تار کو مکمل طور پر ہٹا دیا گیا ہے۔ وائٹ اسپیس وہی ہے جو ہم نے چھوڑی ہے۔ترجمہ شدہ "a" حروف کے درمیان۔ پھر دوبارہ، یہ استفسار:
ترجمہ ('ہیلو، میرا نام انیگو مونٹویا ہے، آپ نے میرے والد کو مار ڈالا، مرنے کی تیاری کریں','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','******************************************)
…اس میں کوئی مسئلہ نہیں ہے اور ایسا نتیجہ نکلتا ہے جو اس طرح لگتا ہے:
"***********************************************************
یہ آپ کو پریشان کر سکتا ہے کہ جاوا اسکرپٹ میں بالکل وہی کام کرنے کا کوئی آسان طریقہ نہیں ہے جو XPath ٹرانسلیٹ فنکشن کرتا ہے، حالانکہ بہت سے استعمال کے معاملات کے لیے، ریگولر ایکسپریشن کے ساتھ ریپلیس آل اسے سنبھال سکتا ہے۔ آپ وہی طریقہ استعمال کرسکتے ہیں جس کا میں نے مظاہرہ کیا ہے، لیکن یہ سب سے بہتر ہے اگر آپ صرف تاروں کا ترجمہ کرنا چاہتے ہیں۔ درج ذیل ڈیمو جاوا اسکرپٹ ورژن فراہم کرنے کے لیے XPath کے ٹرانسلیٹ فنکشن کو لپیٹتا ہے۔ برائن راسموسن کا قلم ترجمہ فنکشن [فورکڈ] دیکھیں۔ آپ ایسی چیز کہاں استعمال کر سکتے ہیں؟ تین جگہوں کے آفسیٹ کے ساتھ سیزر سائفر انکرپشن پر غور کریں (مثلاً، 48 بی سی سے ٹاپ آف دی لائن انکرپشن):
ترجمہ ("سیزر روبیکون کو عبور کرنے کا منصوبہ بنا رہا ہے!"، "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"، "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
ان پٹ ٹیکسٹ "سیزر روبیکون کو عبور کرنے کا منصوبہ بنا رہا ہے!" نتیجے میں "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" مختلف امکانات کی ایک اور تیز مثال دینے کے لیے، میں نے ایک دھاتی فنکشن بنایا جو سٹرنگ ان پٹ لیتا ہے اور متن کو واپس کرنے کے لیے ٹرانسلیٹ فنکشن کا استعمال کرتا ہے، بشمول وہ تمام حروف جو umlauts لیتے ہیں۔ برائن راسموسن کا قلمی دھات کا فنکشن [فورکڈ] دیکھیں۔
const metal = (str) => { واپسی کا ترجمہ (str, "AOUaou","ÄÖÜäöü")؛ }
اور، اگر متن دیا جائے "Motley Crue رولز، rock on dudes!"، تو "Mötley Crüe rüles, röck ön düdes!" لوٹاتا ہے۔ ظاہر ہے، کسی کے پاس اس فنکشن کے ہر طرح کے پیروڈی استعمال ہوسکتے ہیں۔ اگر یہ آپ ہیں، تو یہ TVTropes مضمون آپ کو کافی ترغیب فراہم کرے گا۔ XPath کے ساتھ CSS کا استعمال XPath کے ساتھ مل کر CSS سلیکٹرز کو استعمال کرنے کی ہماری بنیادی وجہ یاد رکھیں: CSS کافی حد تک سمجھتا ہے کہ کلاس کیا ہے، جبکہ XPath کے ساتھ آپ جو سب سے بہتر کام کر سکتے ہیں وہ کلاس انتساب کا سٹرنگ موازنہ ہے۔ یہ زیادہ تر معاملات میں کام کرے گا۔ لیکن اگر آپ کو کبھی ایسی صورت حال کا سامنا کرنا پڑتا ہے جہاں، کہیں، کسی نے .primaryLinks اور .primaryLinks2 کے نام سے کلاسز بنائی ہوں اور آپ .primaryLinks کلاس حاصل کرنے کے لیے XPath استعمال کر رہے ہوں، تو آپ کو ممکنہ طور پر پریشانی کا سامنا کرنا پڑے گا۔ جب تک کہ اس جیسا کوئی احمقانہ نہیں ہے، آپ شاید XPath استعمال کریں گے۔ لیکن مجھے یہ بتاتے ہوئے دکھ ہوا کہ میں نے ایسی جگہوں پر کام کیا ہے جہاں لوگ اس قسم کی احمقانہ باتیں کرتے ہیں۔ یہاں CSS اور XPath کو ایک ساتھ استعمال کرنے والا ایک اور ڈیمو ہے۔ یہ ظاہر کرتا ہے کہ کیا ہوتا ہے جب ہم کوڈ کو ایک سیاق و سباق کے نوڈ پر XPath چلانے کے لیے استعمال کرتے ہیں جو دستاویز کا نوڈ نہیں ہے۔ Bryan Rasmussen کے ذریعے Pen css اور xpath کو ایک ساتھ دیکھیں۔ CSS استفسار .relatedarticles a ہے، جو .relatedarticles کلاس تفویض کردہ div میں دو عناصر کو حاصل کرتا ہے۔ اس کے بعد تین "خراب" سوالات ہیں، یعنی کہنے کے لیے، وہ سوالات جو وہ نہیں کرتے جو ہم ان سے کرنا چاہتے ہیں جب ان عناصر کے ساتھ سیاق و سباق کے نوڈ کے طور پر چلتے ہیں۔ میں وضاحت کر سکتا ہوں کہ وہ آپ کی توقع سے مختلف کیوں کر رہے ہیں۔ زیربحث تین برے سوالات یہ ہیں:
//text(): دستاویز میں موجود تمام متن کو لوٹاتا ہے۔ //a/text(): دستاویز میں موجود لنکس کے اندر موجود تمام متن کو لوٹاتا ہے۔ ./a/text(): کوئی نتیجہ نہیں دیتا۔
ان نتائج کی وجہ یہ ہے کہ جب کہ آپ کا سیاق و سباق CSS استفسار سے لوٹا ہوا عنصر ہے، // پوری دستاویز کے خلاف ہے۔ یہ XPath کی طاقت ہے؛ سی ایس ایس نوڈ سے آباؤ اجداد تک اور پھر اس باپ دادا کے بہن بھائی تک نہیں جا سکتا، اور اس بہن بھائی کی اولاد تک نہیں جا سکتا۔ لیکن XPath کر سکتا ہے۔ دریں اثنا، ./ موجودہ نوڈ کے بچوں سے استفسار کرتا ہے، جہاں ڈاٹ (.) موجودہ نوڈ کی نمائندگی کرتا ہے، اور فارورڈ سلیش (/) کچھ چائلڈ نوڈ پر جانے کی نمائندگی کرتا ہے — چاہے یہ کوئی وصف، عنصر ہو، یا متن کا تعین راستے کے اگلے حصے سے ہوتا ہے۔ لیکن CSS استفسار کے ذریعہ منتخب کردہ کوئی عنصر نہیں ہے، اس طرح وہ استفسار بھی کچھ نہیں لوٹاتا ہے۔ اس آخری ڈیمو میں تین اچھے سوالات ہیں:
.//text(), ./text(), normalize-space(./text())۔
نارملائز-اسپیس استفسار XPath فنکشن کے استعمال کو ظاہر کرتا ہے، لیکن دیگر سوالات میں شامل ایک مسئلہ کو بھی حل کرتا ہے۔ ایچ ٹی ایم ایل کی ساخت اس طرح ہے:
Selenium WebDriver کے ساتھ اپنی فیچر ٹیسٹنگ کو خودکار بنانا
استفسار ٹیکسٹ نوڈ کے شروع اور آخر میں ایک لائن فیڈ لوٹاتا ہے،اور نارملائز-اسپیس اسے ہٹاتا ہے۔ کسی بھی XPath فنکشن کا استعمال کرنا جو بولین کے علاوہ ان پٹ XPath کے ساتھ کچھ اور لوٹاتا ہے دوسرے فنکشنز پر لاگو ہوتا ہے۔ مندرجہ ذیل ڈیمو متعدد مثالیں دکھاتا ہے: Bryan Rasmussen کی Pen xpath فنکشنز کی مثالیں [فورکڈ] دیکھیں۔ پہلی مثال ایک مسئلہ دکھاتی ہے جس پر آپ کو دھیان دینا چاہیے۔ خاص طور پر، درج ذیل کوڈ:
document.queryXPaths("substring-after(//a/@href,'https://')")؛
…ایک تار لوٹاتا ہے:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
یہ سمجھ میں آتا ہے، ٹھیک ہے؟ یہ فنکشن ارے نہیں بلکہ سنگل سٹرنگز یا سنگل نمبرز واپس کرتے ہیں۔ متعدد نتائج کے ساتھ فنکشن کو کہیں بھی چلانے سے صرف پہلا نتیجہ آتا ہے۔ دوسرا نتیجہ ظاہر کرتا ہے کہ ہم واقعی کیا چاہتے ہیں:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
جو دو تاروں کی ایک صف کو لوٹاتا ہے:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath فنکشنز کو جاوا اسکرپٹ کے فنکشنز کی طرح نیسٹ کیا جا سکتا ہے۔ لہذا، اگر ہم Smashing Magazine URL ڈھانچہ جانتے ہیں، تو ہم درج ذیل کام کر سکتے ہیں (ٹیمپلیٹ لٹریلز استعمال کرنے کی سفارش کی جاتی ہے): ترجمہ ( سبسٹرنگ( substring-after(./@href, 'www.smashingmagazine.com/') 9) '/'، '')''
یہ اس حد تک قدرے پیچیدہ ہوتا جا رہا ہے کہ اسے تبصروں کی ضرورت ہے جو یہ بیان کرتے ہیں کہ یہ کیا کرتا ہے: www.smashingmagazine.com/ کے بعد href انتساب سے تمام URL لیں، پہلے نو حروف کو ہٹا دیں، پھر فارورڈ سلیش (/) کریکٹر کا ترجمہ کچھ نہ کریں تاکہ ختم ہونے والے فارورڈ سلیش سے چھٹکارا حاصل کیا جا سکے۔ نتیجے میں صف:
["فیچر-ٹیسٹنگ-سیلینیم-ویب ڈرائیور"،"خودکار-ٹیسٹ-نتائج-بہتری-رسائی"]
مزید XPath استعمال کے کیسز XPath واقعی جانچ میں چمک سکتا ہے۔ وجہ دیکھنا مشکل نہیں ہے، کیونکہ XPath کو DOM میں ہر عنصر کو DOM میں کسی بھی پوزیشن سے حاصل کرنے کے لیے استعمال کیا جا سکتا ہے، جبکہ CSS نہیں کر سکتا۔ آپ بہت سے جدید تعمیراتی نظاموں میں سی ایس ایس کی کلاسوں کے مستقل رہنے پر بھروسہ نہیں کر سکتے ہیں، لیکن XPath کے ساتھ، ہم بدلتے ہوئے DOM ڈھانچے سے قطع نظر، کسی عنصر کا متنی مواد کیا ہے اس کے بارے میں زیادہ مضبوط میچ کرنے کے قابل ہیں۔ ایسی تکنیکوں پر تحقیق ہوئی ہے جو آپ کو لچکدار XPath ٹیسٹ کرنے کی اجازت دیتی ہیں۔ ٹیسٹ فلک آؤٹ ہونے اور ناکام ہونے سے کوئی بھی بدتر نہیں ہے صرف اس وجہ سے کہ CSS سلیکٹر اب کام نہیں کرتا ہے کیونکہ کسی چیز کا نام تبدیل یا ہٹا دیا گیا ہے۔ XPath ایک سے زیادہ لوکیٹر نکالنے میں بھی بہت اچھا ہے۔ کسی عنصر سے ملنے کے لیے XPath استفسارات کو استعمال کرنے کے ایک سے زیادہ طریقے ہیں۔ سی ایس ایس کے ساتھ بھی ایسا ہی ہے۔ لیکن XPath کے استفسارات زیادہ اہدافی طریقے سے چیزوں میں ڈرل کر سکتے ہیں جو واپس آنے والی چیزوں کو محدود کرتا ہے، جس سے آپ کو ایک مخصوص میچ تلاش کرنے کی اجازت ملتی ہے جہاں کئی ممکنہ مماثلتیں ہو سکتی ہیں۔ مثال کے طور پر، ہم ایک مخصوص h2 عنصر کو واپس کرنے کے لیے XPath کا استعمال کر سکتے ہیں جو ایک div کے اندر موجود ہے جو فوری طور پر ایک بہن بھائی div کی پیروی کرتا ہے جس کے نتیجے میں، اس پر ڈیٹا-testID="leader" وصف کے ساتھ چائلڈ امیج عنصر ہوتا ہے:
یہ سرخی حاصل نہ کریں
یہ سرخی بھی حاصل نہ کریں
لیڈر امیج کے لیے ہیڈر
یہ استفسار ہے: document.queryXPaths(` //div[ مندرجہ ذیل بہن بھائی::div[1] /img[@data-testID='لیڈر'] ] /h2/ متن() `);
آئیے یہ دیکھنے کے لیے ایک ڈیمو ڈالیں کہ یہ سب کیسے اکٹھا ہوتا ہے: برائن راسموسن کی قلم کمپلیکس H2 استفسار [فورکڈ] دیکھیں۔ تو، ہاں۔ XPath کا استعمال کرتے ہوئے ٹیسٹ میں کسی بھی عنصر کے بہت سے ممکنہ راستے ہیں۔ XSLT 1.0 فرسودگی میں نے ابتدائی طور پر ذکر کیا تھا کہ کروم ٹیم براؤزر سے XSLT 1.0 سپورٹ کو ہٹانے کا ارادہ رکھتی ہے۔ یہ اس لیے اہم ہے کیونکہ XSLT 1.0 دستاویز کی تبدیلی کے لیے XML مرکوز پروگرامنگ کا استعمال کرتا ہے جو کہ بدلے میں XPath 1.0 پر انحصار کرتا ہے، جو زیادہ تر براؤزرز میں پایا جاتا ہے۔ جب ایسا ہوتا ہے، تو ہم XPath کا ایک اہم جزو کھو دیں گے۔ لیکن اس حقیقت کو دیکھتے ہوئے کہ XPath ٹیسٹ لکھنے کے لیے واقعی بہت اچھا ہے، مجھے یہ امکان نہیں ہے کہ XPath مجموعی طور پر جلد ہی کسی بھی وقت غائب ہو جائے۔ اس نے کہا، میں نے محسوس کیا ہے کہ جب کسی خصوصیت کو چھین لیا جاتا ہے تو لوگ اس میں دلچسپی لیتے ہیں۔ اور یہ یقینی طور پر XSLT 1.0 کے فرسودہ ہونے کی صورت میں درست ہے۔ ہیکر نیوز میں فرسودگی کے خلاف دلائل سے بھری ہوئی ایک پوری بحث ہو رہی ہے۔ پوسٹ خود XSLT کے ساتھ بلاگنگ فریم ورک بنانے کی ایک بہترین مثال ہے۔ آپبحث کو اپنے لیے پڑھ سکتے ہیں، لیکن یہ اس بات کی طرف جاتا ہے کہ اس قسم کے معاملات کو سنبھالنے کے لیے XLST کے لیے جاوا اسکرپٹ کو کیسے استعمال کیا جا سکتا ہے۔ میں نے یہ تجاویز بھی دیکھی ہیں کہ براؤزرز کو SaxonJS استعمال کرنا چاہیے، جو JavaScript کے Saxon XSLT، XQUERY، اور XPath انجنوں کے لیے ایک پورٹ ہے۔ یہ ایک دلچسپ خیال ہے، خاص طور پر جیسا کہ Saxon-JS ان تصریحات کے موجودہ ورژن کو لاگو کرتا ہے، جب کہ ایسا کوئی براؤزر نہیں ہے جو XPath یا XSLT کے کسی بھی ورژن کو 1.0 سے آگے نافذ کرتا ہو، اور کوئی بھی ایسا نہیں جو XQuery کو نافذ کرے۔ میں Saxonica میں Norm Tovey-Walsh تک پہنچا، جو SaxonJS اور Saxon انجن کے دوسرے ورژن کے پیچھے والی کمپنی ہے۔ فرمایا: "اگر کوئی براؤزر فروش SaxonJS کو براؤزر میں جدید XML ٹیکنالوجیز کو ضم کرنے کے نقطہ آغاز کے طور پر لینے میں دلچسپی رکھتا ہے، تو ہمیں ان کے ساتھ اس پر بات کرنے میں بہت خوشی ہوگی۔"- نارم ٹووی والش
لیکن یہ بھی شامل کیا گیا: "مجھے بہت حیرت ہوگی اگر کوئی یہ سوچے کہ SaxonJS کو اس کی موجودہ شکل میں لینا اور اسے براؤزر کی تعمیر میں کوئی تبدیلی نہیں لانا مثالی نقطہ نظر ہوگا۔ ایک براؤزر فروش، فطرت کے لحاظ سے کہ وہ براؤزر بناتے ہیں، انضمام کو اس سے کہیں زیادہ گہری سطح پر پہنچا سکتا ہے جتنا ہم 'باہر سے' کر سکتے ہیں۔"- Norm Tovey-Walsh
یہ بات قابل غور ہے کہ Tovey-Walsh کے تبصرے XSLT فرسودگی کے اعلان سے تقریباً ایک ہفتہ پہلے آئے تھے۔ نتیجہ میں آگے بڑھ سکتا تھا۔ لیکن مجھے امید ہے کہ اس نے XPath کی طاقت کا مظاہرہ کیا ہے اور آپ کو بہت ساری مثالیں دی ہیں جو یہ ظاہر کرتی ہیں کہ اسے عظیم چیزوں کے حصول کے لیے کیسے استعمال کیا جائے۔ یہ براؤزر اسٹیک میں پرانی ٹکنالوجی کی ایک بہترین مثال ہے جس میں آج بھی کافی افادیت موجود ہے، یہاں تک کہ اگر آپ نے کبھی نہیں جانا کہ یہ موجود ہے یا کبھی اس تک پہنچنے پر غور نہیں کیا۔ مزید پڑھنا
"قدرتی زبان کے ساتھ خودکار ویب ٹیسٹوں کی لچک کو بڑھانا" (ACM ڈیجیٹل لائبریری) بذریعہ Maroun Ayli، Youssef Bakouny، Nader Jalloul، اور Rima Kilany یہ مضمون لچکدار ٹیسٹ لکھنے کے لیے XPath کی بہت سی مثالیں فراہم کرتا ہے۔ XPath (MDN)اگر آپ ایک تکنیکی وضاحت چاہتے ہیں کہ XPath کیسے کام کرتا ہے تو یہ شروع کرنے کے لیے ایک بہترین جگہ ہے۔ XPath ٹیوٹوریل (ZVON)میں نے اس ٹیوٹوریل کو اپنے سیکھنے میں سب سے زیادہ مددگار ثابت کیا ہے، بہت ساری مثالوں اور واضح وضاحتوں کی بدولت۔ XPather یہ انٹرایکٹو ٹول آپ کو کوڈ کے ساتھ براہ راست کام کرنے دیتا ہے۔
