من آنقدر در توسعه front-end بودهام که بتوانم طی سالها روندی را ببینم: توسعهدهندگان جوانتر با الگوی جدیدی از برنامهنویسی بدون درک بافت تاریخی آن کار میکنند. البته ندانستن چیزی کاملاً قابل درک است. وب مکانی بسیار بزرگ با مجموعهای از مهارتها و تخصصهای متنوع است و ما همیشه چیزهایی را که نمیدانیم نمیدانیم. یادگیری در این زمینه یک سفر مداوم است تا چیزی که یک بار اتفاق می افتد و به پایان می رسد. نمونه موردی: یکی از اعضای تیم من پرسید که آیا می توان تشخیص داد که آیا کاربران از یک برگه خاص در رابط کاربری دور می شوند یا خیر. من به رویداد قبل از بارگیری جاوا اسکریپت اشاره کردم. اما کسانی که قبلاً با این موضوع مقابله کردهاند میدانند که این امکان پذیر است زیرا هشدارهایی در مورد دادههای ذخیرهنشده در سایتهای دیگر دریافت کردهاند، که قبل از بارگیری یک مورد استفاده معمولی است. من همچنین رویدادهای pageHide و visibilityChange را برای اندازه گیری خوب به همکارم اشاره کردم. من از کجا از آن مطلع شدم؟ به این دلیل که در پروژه دیگری مطرح شد، نه به این دلیل که در ابتدای یادگیری جاوا اسکریپت روی آن مطالعه کردم. واقعیت این است که فریمورکهای فرانتاند مدرن بر روی شانههای غولهای فناوری که قبل از آنها بودند، ایستادهاند. آنها شیوههای توسعه را انتزاعی میکنند، اغلب برای یک تجربه توسعهدهنده بهتر که نیاز به دانستن یا لمس آنچه را که بهطور سنتی مفاهیم اولیه ضروری بودهاند، کاهش میدهد یا حتی از بین میبرد. مدل شیء CSS (CSSM) را در نظر بگیرید. ممکن است انتظار داشته باشید که هرکسی که در CSS و جاوا اسکریپت کار می کند، یک سری تجربه عملی 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 می توانند برای یافتن بیشتر عناصر در صفحه شما استفاده شوند، نمی توانند همه آنها را پیدا کنند. علاوه بر این، انتخابگرهای CSS را نمی توان برای یافتن یک عنصر بر اساس موقعیت فعلی آن در DOM استفاده کرد. XPath می تواند. اکنون، برخی از شما که این را می خوانید ممکن است XPath را بدانید و برخی ممکن است ندانند. XPath حوزه بسیار بزرگی از فناوری است، و من واقعاً نمیتوانم همه اصول اولیه را آموزش دهم و همچنین کارهای جالبی را که باید با آن انجام دهید در یک مقاله مانند این به شما نشان دهم. من در واقع سعی کردم آن مقاله را بنویسم، اما میانگین انتشار مجله Smashing بیش از 5000 کلمه نیست. من در حال حاضر در بیش از2000 کلمه در حالی که فقط در نیمه راه از اصول اولیه است. بنابراین، من میخواهم کارهای جالبی را با XPath انجام دهم و به شما پیوندهایی میدهم که اگر این موارد برایتان جالب بود، میتوانید از آنها برای اصول اولیه استفاده کنید. ترکیب XPath و CSS XPath می تواند کارهای زیادی را انجام دهد که انتخابگرهای CSS نمی توانند هنگام پرس و جو از عناصر انجام دهند. اما انتخابگرهای CSS همچنین میتوانند کارهایی را انجام دهند که XPath نمیتواند آنها را انجام دهد، مثلاً عناصر را با نام کلاس پرس و جو کند.
CSS XPath myClass /*[شامل(@class، "myClass")]
در این مثال، CSS عناصری را که حاوی نام کلاس .myClass هستند را جستوجو میکند. در همین حال، مثال XPath عناصری را که حاوی یک کلاس ویژگی با رشته «myClass» هستند، پرس و جو می کند. به عبارت دیگر، عناصری را با myClass در هر ویژگی، از جمله عناصر با نام کلاس myClass. و همچنین عناصری با "myClass" در رشته، مانند myClass2. انتخاب میکند. XPath از این نظر گسترده تر است. بنابراین، نه. من پیشنهاد نمی کنم که CSS را کنار بگذاریم و شروع به انتخاب همه عناصر از طریق XPath کنیم. نکته این نیست. نکته این است که XPath می تواند کارهایی را انجام دهد که CSS نمی تواند و هنوز هم می تواند بسیار مفید باشد، حتی اگر یک فناوری قدیمی در پشته مرورگر است و ممکن است در نگاه اول واضح به نظر نرسد. بیایید از این دو فناوری با هم استفاده کنیم، نه تنها به این دلیل که میتوانیم، بلکه به این دلیل که در این فرآیند چیزی در مورد XPath یاد میگیریم و آن را به ابزار دیگری در پشته شما تبدیل میکنیم – یکی از ابزارهایی که ممکن است نمیدانستید همیشه وجود داشته است! مشکل این است که روش document.evaluate جاوا اسکریپت و روشهای انتخابگر پرس و جوی مختلفی که با APIهای CSS برای جاوا اسکریپت استفاده میکنیم، ناسازگار هستند. من یک API پرسوجو سازگار ساختهام تا کارمان را شروع کنم، اگرچه مسلماً فکر زیادی در مورد آن نکردهام زیرا این یک انحراف از کاری است که در اینجا انجام میدهیم. در اینجا یک نمونه کار نسبتاً ساده از سازنده پرس و جو قابل استفاده مجدد آورده شده است: به QueryXPath قلم [فشار شده] توسط برایان راسموسن مراجعه کنید. من دو روش را روی شی سند اضافه کرده ام: queryCSSSelectors (که در اصل querySelectorAll است) و queryXPaths. هر دوی اینها یک شی queryResults را برمیگردانند:
{ queryType: گره ها | رشته | شماره | بولی، نتایج: هر[] // عناصر html، عناصر xml، رشته ها، اعداد، بولی ها، انتخابگرهای queryCSSS: (پرس و جو: رشته، اصلاح: بولی) => queryResults، queryXpaths: (query: string, amend: boolean) => queryResults }
توابع queryCSSSselctors و queryXpaths پرس و جوی را که به آنها میدهید روی عناصر آرایه نتایج اجرا میکنند، البته تا زمانی که آرایه نتایج از نوع گرهها باشد. در غیر این صورت، یک queryResult با یک آرایه خالی و یک نوع گره برمی گرداند. اگر ویژگی amend روی true تنظیم شود، توابع queryResults خود را تغییر خواهند داد. تحت هیچ شرایطی نباید از این در محیط تولید استفاده شود. من این کار را صرفاً برای نشان دادن اثرات مختلف استفاده از دو کوئری API با هم انجام می دهم. پرس و جوهای نمونه من می خواهم چند نمونه از پرس و جوهای مختلف XPath را نشان دهم که برخی از کارهای قدرتمندی را که می توانند انجام دهند و نحوه استفاده از آنها به جای سایر رویکردها را نشان می دهد. اولین مثال //li/text() است. این همه عناصر li را پرس و جو می کند و گره های متنی آنها را برمی گرداند. بنابراین، اگر بخواهیم HTML زیر را پرس و جو کنیم:
- یک
- دو
- سه
... این چیزی است که برگردانده می شود:
{"queryType":"xpathEvaluate"، "results":["one"، "two"، "three"],"resultType":"string"}
به عبارت دیگر، آرایه زیر را دریافت می کنیم: ["یک"، "دو"، "سه"]. به طور معمول، شما باید برای عناصر li پرس و جو کنید تا آن را دریافت کنند، نتیجه آن کوئری را به یک آرایه تبدیل کنید، آرایه را نقشه برداری کنید و گره متن هر عنصر را برگردانید. اما میتوانیم این کار را به طور خلاصهتر با XPath انجام دهیم: document.queryXPaths("//li/text()").نتایج.
توجه داشته باشید که راه دریافت یک گره متنی استفاده از text() است که شبیه یک امضای تابع است - و همینطور است. گره متن یک عنصر را برمی گرداند. در مثال ما، سه عنصر li در نشانه گذاری وجود دارد که هر کدام حاوی متن است ("یک"، "دو" و "سه").
بیایید به یک مثال دیگر از پرس و جوی ()Text نگاه کنیم. فرض کنید این نشانه گذاری ما است:
بیایید یک پرس و جو بنویسیم که مقدار ویژگی href را برمی گرداند: document.queryXPaths("//a[text() = 'ورود به سیستم']/@href").نتایج.
این یک کوئری XPath در سند جاری است، درست مانند مثال آخر، اما این بار ویژگی href یک پیوند (یک عنصر) را که حاوی متن "ورود به سیستم" است، برمی گردانیم. واقعی برگشتنتیجه ["/login.html"] است. بررسی اجمالی توابع XPath تعدادی از توابع XPath وجود دارد و احتمالاً با آنها آشنایی ندارید. من فکر می کنم چندین مورد وجود دارد که ارزش دانستن دارد، از جمله موارد زیر:
starts-withاگر متنی با یک مثال متنی خاص شروع میشود، starts-with(@href، 'http:') اگر ویژگی href با http: شروع شود true برمیگرداند. containIf یک متن حاوی یک مثال متن خاص دیگر باشد، contain(text()، "Smashing Magazine") اگر یک گره متنی حاوی کلمات "Smashing Magazine" در هر جایی باشد، true را برمی گرداند. count تعداد موارد منطبق برای یک پرس و جو را برمی گرداند. برای مثال، count(//*[starts-with(@href, 'http:']) تعداد پیوندهایی را در گره زمینه دارای عناصری با ویژگی href است که حاوی متنی است که با http: شروع می شود، برمی گرداند. substring مانند زیر رشته جاوا اسکریپت کار می کند، به جز اینکه رشته را به عنوان آرگومان ارسال می کنید. برای مثال، substring("my text", 2, 4) "y t" را برمی گرداند. substring-before بخشی از یک رشته را قبل از رشته دیگر برمی گرداند. برای مثال، substing-before("متن من"، "") "my" را برمی گرداند. به طور مشابه، substring-before("hi","bye") یک رشته خالی برمی گرداند. substring-after بخشی از یک رشته را پس از رشته دیگر برمی گرداند. برای مثال، substing-after("متن من"، "") "متن" را برمی گرداند. به طور مشابه، substring-after("hi","bye") یک رشته خالی را برمی گرداند. normalize-space رشته آرگومان را با فضای سفید نرمال شده با حذف فضای سفید پیشرو و انتهایی و جایگزینی دنباله ای از کاراکترهای فضای خالی با یک فاصله منفرد برمی گرداند. در صورتی که آرگومان نادرست باشد، مقدار درست بولی را برمیگرداند، در غیر این صورت نادرست است. trueBolean true را برمی گرداند. false غلط بولی را برمی گرداند. concat همان چیزی است که جاوا اسکریپت concat است، با این تفاوت که شما آن را به عنوان یک متد روی یک رشته اجرا نمی کنید. در عوض، تمام رشته هایی را که می خواهید به هم متصل کنید، قرار می دهید. string-lengthاین با طول رشته جاوا اسکریپت یکسان نیست، بلکه طول رشته ای را که به عنوان آرگومان داده شده را برمی گرداند. translateThis یک رشته می گیرد و آرگومان دوم را به آرگومان سوم تغییر می دهد. به عنوان مثال، translate ("abcdef", "abc"، "XYZ") خروجی XYZdef را ارائه می دهد.
به غیر از این توابع خاص XPath، تعدادی توابع دیگر وجود دارند که دقیقاً مانند همتایان جاوا اسکریپت خود - یا همتایان در اساساً در هر زبان برنامه نویسی - کار می کنند که احتمالاً برای شما مفید هستند، مانند کف، سقف، گرد، جمع و غیره. نسخه ی نمایشی زیر هر یک از این عملکردها را نشان می دهد: توابع عددی قلم XPath [فشار گرفته شده] توسط برایان راسموسن را ببینید. توجه داشته باشید که مانند بسیاری از توابع دستکاری رشته، بسیاری از توابع عددی یک ورودی واحد می گیرند. البته این به این دلیل است که قرار است از آنها برای پرس و جو استفاده شود، مانند آخرین مثال XPath: //li[floor(text()) > 250]/@val
اگر از آنها استفاده کنید، همانطور که بیشتر نمونه ها انجام می دهند، در نهایت آن را در اولین گره ای که با مسیر مطابقت دارد اجرا می کنید. همچنین برخی از توابع تبدیل نوع وجود دارد که احتمالاً باید از آنها اجتناب کنید زیرا جاوا اسکریپت قبلاً مشکلات تبدیل نوع خاص خود را دارد. اما ممکن است مواقعی وجود داشته باشد که بخواهید یک رشته را به عدد تبدیل کنید تا آن را در مقابل یک عدد دیگر بررسی کنید. توابعی که نوع چیزی را تعیین می کنند عبارتند از: بولی، عدد، رشته و گره. اینها انواع داده های مهم XPath هستند. و همانطور که ممکن است تصور کنید، بیشتر این توابع را می توان در انواع داده هایی که گره های DOM نیستند استفاده کرد. برای مثال، substring-after رشتهای را همانطور که قبلاً پوشش دادهایم میگیرد، اما میتواند رشتهای از یک ویژگی href باشد. همچنین می تواند فقط یک رشته باشد:
const testSubstringAfter = document.queryXPaths("substring-after('Hello world',' ')");
بدیهی است که این مثال آرایه نتایج را به عنوان ["جهان"] به ما باز می گرداند. برای نشان دادن این در عمل، من یک صفحه نمایشی با استفاده از توابع در برابر چیزهایی که گرههای DOM نیستند ساختهام: به QueryXPath قلم [فشار شده] توسط برایان راسموسن مراجعه کنید. باید به جنبه شگفتانگیز تابع translate توجه کنید، این است که اگر یک کاراکتر در آرگومان دوم (یعنی لیست کاراکترهایی که میخواهید ترجمه شوند) داشته باشید و هیچ کاراکتری منطبق برای ترجمه به آن وجود نداشته باشد، آن کاراکتر از خروجی حذف میشود. بنابراین، این:
translate('سلام، نام من اینیگو مونتویا است، شما پدرم را کشتید، برای مردن آماده شوید','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
... نتایج در رشته، از جمله فاصله: ["***"]
این بدان معناست که حرف "a" به یک ستاره (*) ترجمه می شود، اما هر کاراکتر دیگری که با توجه به رشته هدف ترجمه ندارد، به طور کامل حذف می شود. فضای خالی تنها چیزی است که برای ما باقی مانده استبین کاراکترهای ترجمه شده "a". سپس دوباره این پرس و جو:
translate('سلام، اسم من اینیگو مونتویا است، تو پدرم را کشتی، برای مردن آماده شو','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','***********************************************')")
... مشکلی ندارد و نتیجه ای به شکل زیر می دهد:
"******** **************************************************************************"
ممکن است متوجه شوید که هیچ راه آسانی در جاوا اسکریپت برای انجام دقیقا همان کاری که تابع XPath translate انجام می دهد وجود ندارد، اگرچه برای بسیاری از موارد استفاده، جایگزین All با عبارات منظم می تواند آن را انجام دهد. میتوانید از همان رویکردی که من نشان دادم استفاده کنید، اما اگر تنها چیزی که میخواهید این باشد که رشتهها را ترجمه کنید، کمتر از حد مطلوب است. نسخه ی نمایشی زیر تابع ترجمه XPath را برای ارائه یک نسخه جاوا اسکریپت پیچیده می کند: تابع ترجمه قلم [فورک شده] توسط برایان راسموسن را ببینید. کجا می توانید از چنین چیزی استفاده کنید؟ رمزگذاری Caesar Cipher را با افست سه مکان در نظر بگیرید (به عنوان مثال، رمزگذاری برتر از 48 قبل از میلاد):
translate("سزار قصد دارد از روبیکون عبور کند!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
متن ورودی "سزار در حال برنامه ریزی برای عبور از روبیکون است!" منجر به "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" برای ارائه یک مثال سریع دیگر از احتمالات مختلف، من یک تابع فلزی ساختم که ورودی رشته را می گیرد و از یک تابع ترجمه برای برگرداندن متن استفاده می کند، شامل همه کاراکترهایی که umlaut می گیرند. تابع فلز قلم [چنگال شده] توسط برایان راسموسن را ببینید.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
و اگر متن "Motley Crue rule, rock on dudes!" به آن داده شود "Mötley Crüe rüles, röck ön düdes!" بدیهی است که ممکن است همه انواع استفاده های تقلید آمیز از این تابع داشته باشند. اگر این شما هستید، پس این مقاله TVTropes باید الهام زیادی برای شما فراهم کند. استفاده از CSS با XPath دلیل اصلی ما برای استفاده از انتخابگرهای CSS همراه با XPath را به خاطر داشته باشید: CSS تقریباً میداند یک کلاس چیست، در حالی که بهترین کاری که میتوانید با XPath انجام دهید، مقایسه رشتهای ویژگی کلاس است. که در بیشتر موارد کار خواهد کرد. اما اگر قرار بود در موقعیتی قرار بگیرید که مثلاً فردی کلاس هایی به نام های .primaryLinks و .primaryLinks2 ایجاد کند و شما از XPath برای دریافت کلاس .primaryLinks استفاده کنید، احتمالاً با مشکل مواجه می شوید. تا زمانی که هیچ چیز احمقانه ای وجود نداشته باشد، احتمالاً از XPath استفاده خواهید کرد. اما با ناراحتی می گویم که در مکان هایی کار کرده ام که مردم آن نوع کارهای احمقانه را انجام می دهند. در اینجا یک نسخه آزمایشی دیگر با استفاده از CSS و XPath با هم وجود دارد. این نشان می دهد که وقتی از کد برای اجرای یک XPath در گره زمینه ای استفاده می کنیم که گره سند نیست، چه اتفاقی می افتد. قلم css و xpath را با هم [فورک شده] توسط برایان راسموسن ببینید. پرس و جو CSS .relatedarticles a است که دو عنصر a را در یک div اختصاص داده شده به کلاس .relatedarticles واکشی می کند. پس از آن، سه پرسوجو «بد» قرار دارند، یعنی پرسوجوهایی که هنگام اجرا با این عناصر بهعنوان گره زمینه، کاری را که ما میخواهیم انجام نمیدهند. من می توانم توضیح دهم که چرا آنها متفاوت از آنچه شما انتظار دارید رفتار می کنند. سه سوال بد مورد بحث عبارتند از:
//text(): تمام متن موجود در سند را برمیگرداند. //a/text(): تمام متن داخل پیوندهای سند را برمیگرداند. ./a/text(): هیچ نتیجه ای را بر نمی گرداند.
دلیل این نتایج این است که در حالی که زمینه شما عنصری است که از کوئری CSS بازگردانده شده است، // برخلاف کل سند است. این نقطه قوت XPath است. CSS نمی تواند از یک گره به یک اجداد و سپس به خواهر یا برادر آن اجداد برود و به نسل آن خواهر یا برادر برسد. اما XPath می تواند. در همین حال، ./ فرزندان گره فعلی را جستجو می کند، جایی که نقطه (.) نشان دهنده گره فعلی است، و اسلش رو به جلو (/) نشان دهنده رفتن به یک گره فرزند است - اینکه آیا این یک ویژگی، عنصر یا متن است که توسط قسمت بعدی مسیر تعیین می شود. اما هیچ عنصر فرزندی وجود ندارد که توسط کوئری CSS انتخاب شده باشد، بنابراین آن کوئری نیز چیزی را برمی گرداند. سه پرس و جو خوب در آخرین نسخه نمایشی وجود دارد:
.//text()، ./text(), normalize-space(./text()).
پرس و جو normalize-space استفاده از تابع XPath را نشان می دهد، اما مشکلی را که در سایر کوئری ها وجود دارد را نیز برطرف می کند. ساختار HTML به این صورت است:
خودکار کردن تست ویژگی های خود با Selenium WebDriver
پرس و جو یک خوراک خط در ابتدا و انتهای گره متن برمی گرداند،و normalize-space این را حذف می کند. استفاده از هر تابع XPath که چیزی غیر از یک بولی را با ورودی XPath برمی گرداند، برای توابع دیگر اعمال می شود. دمو زیر تعدادی نمونه را نشان می دهد: نمونههای توابع قلم xpath [فشار شده] توسط برایان راسموسن را ببینید. مثال اول مشکلی را نشان می دهد که باید مراقب آن باشید. به طور مشخص کد زیر:
document.queryXPaths("substring-after(//a/@href,'https://')");
… یک رشته را برمی گرداند:
"www.smashingmagazine.com/2018/04/تست-ویژگی-سلنیوم-وبدرایور/"
منطقی است، درست است؟ این توابع آرایهها را برمیگردانند، بلکه رشتهها یا اعداد واحد را برمیگردانند. اجرای تابع در هر جایی با چندین نتیجه فقط اولین نتیجه را برمی گرداند. نتیجه دوم نشان می دهد که ما واقعاً چه می خواهیم:
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 می توانند درست مانند توابع در جاوا اسکریپت تو در تو باشند. بنابراین، اگر ساختار URL مجله Smashing را بشناسیم، میتوانیم کارهای زیر را انجام دهیم (استفاده از الگوهای واقعی توصیه میشود): `ترجمه( رشته فرعی( substring-after(./@href، 'www.smashingmagazine.com/') ,9) "/"،")".
این کمی پیچیدهتر میشود تا حدی که نیاز به نظراتی دارد که توضیح دهد چه کار میکند: تمام URL را از ویژگی href بعد از www.smashingmagazine.com/ بردارید، 9 کاراکتر اول را حذف کنید، سپس کاراکتر اسلش جلو (/) را به هیچ ترجمه کنید تا از شر پایانی که به جلو میرود خلاص شوید. آرایه به دست آمده:
["feature-testing-selenium-webdriver", "automated-test-results-improve-accessibility"]
موارد استفاده بیشتر از XPath XPath واقعا می تواند در تست بدرخشد. دلیل آن دشوار نیست، زیرا از XPath می توان برای دریافت هر عنصر در DOM، از هر موقعیتی در DOM استفاده کرد، در حالی که CSS نمی تواند. نمیتوانید روی ثابت ماندن کلاسهای CSS در بسیاری از سیستمهای ساخت مدرن حساب کنید، اما با XPath، ما میتوانیم بدون توجه به تغییر ساختار DOM، مطابقت قویتری با محتوای متنی یک عنصر داشته باشیم. تحقیقاتی در مورد تکنیک هایی انجام شده است که به شما امکان می دهد تست های XPath انعطاف پذیر انجام دهید. هیچ چیز بدتر از این نیست که تست ها از بین بروند و شکست بخورند فقط به این دلیل که انتخابگر CSS دیگر کار نمی کند زیرا چیزی تغییر نام داده یا حذف شده است. XPath همچنین در استخراج مکان یاب چندگانه بسیار عالی است. بیش از یک راه برای استفاده از کوئری های XPath برای مطابقت با یک عنصر وجود دارد. همین امر در مورد CSS نیز صادق است. اما پرسوجوهای XPath میتوانند موارد را به روشی هدفمندتر بررسی کنند که مواردی را که بازگردانده میشوند محدود میکند و به شما امکان میدهد یک تطابق خاص را پیدا کنید که ممکن است چندین تطابق احتمالی وجود داشته باشد. به عنوان مثال، ما میتوانیم از XPath برای برگرداندن یک عنصر h2 خاص استفاده کنیم که در داخل یک div قرار دارد که بلافاصله پس از یک div خواهر و برادری قرار میگیرد که به نوبه خود حاوی یک عنصر تصویر فرزند با ویژگی data-testID="leader" روی آن است:
این عنوان را دریافت نکنید
این عنوان را هم دریافت نکنید
سرصفحه تصویر رهبر
این پرس و جو است: document.queryXPaths(` //div[ زیر-برادر::div[1] /img[@data-testID='leader'] ] /h2/ متن () `);
بیایید یک نسخه ی نمایشی بگذاریم تا ببینیم چگونه این همه با هم جمع می شوند: پرس و جوی Pen Complex H2 [فورک شده] توسط برایان راسموسن را ببینید. بنابراین، بله. بسیاری از مسیرهای ممکن برای هر عنصر در یک تست با استفاده از XPath وجود دارد. XSLT 1.0 منسوخ شد من در ابتدا اشاره کردم که تیم کروم قصد دارد پشتیبانی XSLT 1.0 را از مرورگر حذف کند. این مهم است زیرا XSLT 1.0 از برنامه نویسی متمرکز بر XML برای تبدیل سند استفاده می کند که به نوبه خود به XPath 1.0 متکی است که در اکثر مرورگرها یافت می شود. وقتی این اتفاق بیفتد، یک جزء کلیدی XPath را از دست خواهیم داد. اما با توجه به این واقعیت که XPath برای نوشتن تست ها واقعا عالی است، بعید می دانم که XPath به عنوان یک کل به این زودی ها ناپدید شود. با این اوصاف، متوجه شده ام که وقتی یک ویژگی حذف می شود، مردم به آن علاقه مند می شوند. و این مطمئناً در مورد منسوخ شدن XSLT 1.0 صادق است. یک بحث کامل در هکر نیوز در حال وقوع است که مملو از استدلالهایی علیه این بی اعتباری است. این پست خود نمونه ای عالی از ایجاد یک چارچوب وبلاگ نویسی با XSLT است. شمامی توانید بحث را برای خود بخوانید، اما به این موضوع می پردازیم که چگونه جاوا اسکریپت ممکن است به عنوان شیمی برای XLST برای رسیدگی به این نوع موارد استفاده شود. من همچنین پیشنهاداتی را دیده ام که مرورگرها باید از SaxonJS استفاده کنند، که پورتی برای موتورهای Saxon XSLT، XQUERY و XPath جاوا اسکریپت است. این ایده جالبی است، به خصوص که Saxon-JS نسخه فعلی این مشخصات را پیادهسازی میکند، در حالی که هیچ مرورگری وجود ندارد که نسخهای از XPath یا XSLT را فراتر از 1.0 پیادهسازی کند، و هیچ مرورگری وجود ندارد که XQuery را پیادهسازی کند. من با Norm Tovey-Walsh در Saxonica تماس گرفتم، شرکت پشتیبان SaxonJS و سایر نسخههای موتور Saxon. او گفت: "اگر هر فروشنده مرورگر علاقه مند بود که SaxonJS را به عنوان نقطه شروع برای ادغام فناوری های XML مدرن در مرورگر قرار دهد، ما خوشحال می شویم که در مورد آن با آنها صحبت کنیم." - Norm Tovey-Walsh
اما همچنین اضافه کرد: "من بسیار متعجب خواهم شد اگر کسی فکر کند که SaxonJS را به شکل فعلی آن و رها کردن آن در بیلد مرورگر بدون تغییر رویکرد ایده آلی خواهد بود. یک فروشنده مرورگر، به دلیل ماهیت این واقعیت که مرورگر را می سازد، می تواند به ادغام در سطحی بسیار عمیق تر از آنچه که ما می توانیم "از بیرون" داشته باشیم، نزدیک شود." - Norm Tovey-Walsh.
شایان ذکر است که نظرات Tovey-Walsh حدود یک هفته قبل از اعلام لغو XSLT منتشر شد. نتیجه گیری میتونستم ادامه بدم اما امیدوارم که این قدرت XPath را نشان داده باشد و مثالهای زیادی را به شما ارائه کرده باشد که نشان میدهد چگونه از آن برای دستیابی به چیزهای بزرگ استفاده کنید. این یک نمونه کامل از فناوری قدیمیتر در پشته مرورگر است که امروزه هنوز کاربردهای زیادی دارد، حتی اگر هرگز وجود آن را نمیدانستید یا هرگز فکر نمیکردید به آن دست پیدا کنید. ادامه مطلب
«افزایش انعطافپذیری تستهای وب خودکار با زبان طبیعی» (کتابخانه دیجیتال ACM) توسط مارون آیلی، یوسف باکونی، نادر جلول و ریما کیلانی این مقاله نمونههای XPath زیادی را برای نوشتن تستهای انعطافپذیر ارائه میکند. XPath (MDN) اگر می خواهید توضیحات فنی در مورد نحوه عملکرد XPath ارائه دهید، این مکان عالی برای شروع است. XPath Tutorial (ZVON) به لطف مثالهای فراوان و توضیحات واضح، این آموزش را در یادگیری خودم مفیدترین راهحل دانستم. XPatherاین ابزار تعاملی به شما امکان می دهد مستقیماً با کد کار کنید.
