Mən illər ərzində bir tendensiya görmək üçün kifayət qədər uzun müddətdir ki, qabaqcıl inkişafda olmuşam: gənc tərtibatçılar onun tarixi kontekstini başa düşmədən yeni proqramlaşdırma paradiqması ilə işləyirlər. Nəyisə bilməmək, əlbəttə ki, tamamilə başa düşüləndir. Veb müxtəlif bacarıq və ixtisaslara malik çox böyük bir yerdir və biz həmişə bilmədiklərimizi bilmirik. Bu sahədə öyrənmək bir dəfə baş verən və bitən bir şey deyil, davamlı bir səyahətdir. Nöqteyi-nəzərdən nümunə: Komandamdakı biri istifadəçilərin UI-də müəyyən bir tabdan uzaqlaşdığını söyləmək mümkün olub-olmadığını soruşdu. JavaScript-in yükləmədən əvvəl hadisəsini qeyd etdim. Ancaq əvvəllər bununla məşğul olanlar bunun mümkün olduğunu bilirlər, çünki onlar başqa saytlarda saxlanmamış məlumatlar haqqında xəbərdarlıqlarla üzləşiblər, bunun üçün yükləmədən əvvəl adi istifadə halıdır. Həmkarıma yaxşı ölçü üçün pageHide və visibilityChange hadisələrini də qeyd etdim. Mən bunu hardan bildim? Çünki JavaScript-i ilk dəfə öyrənərkən onun üzərində oxuduğum üçün deyil, başqa bir layihədə ortaya çıxdı. Fakt budur ki, müasir front-end çərçivələr onlardan əvvəlki texnologiya nəhənglərinin çiyinlərində dayanır. Onlar inkişaf təcrübələrini mücərrəd edir, çox vaxt daha yaxşı inkişaf etdirici təcrübəsi üçün hər kəsin yəqin ki, bilməli olduğu ənənəvi əsas qabaqcıl konsepsiyaları bilmək və ya toxunmaq ehtiyacını azaldır və ya hətta aradan qaldırır. CSS Obyekt Modelini (CSSOM) nəzərdən keçirin. CSS və JavaScript-də işləyən hər kəsin çoxlu praktiki CSSOM təcrübəsi olduğunu gözləyə bilərsiniz, lakin bu, həmişə belə olmayacaq. Üzərində işlədiyim e-ticarət saytı üçün React layihəsi var idi, burada hazırda seçilmiş ödəniş provayderi üçün üslub cədvəlini yükləməliydik. Problem onda idi ki, stil cədvəli yalnız müəyyən bir səhifədə lazım olduqda hər səhifəyə yüklənirdi. Bunu etmək vəzifəsi qoyulmuş tərtibatçı heç vaxt stil cədvəlini dinamik şəkildə yükləməmişdi. Yenə də, React əldə edə biləcəyiniz ənənəvi yanaşmanı mücərrədləşdirəndə bu tamamilə başa düşüləndir. CSSOM, çox güman ki, gündəlik işinizdə ehtiyac duyduğunuz bir şey deyil. Ancaq çox güman ki, bir anda, hətta bir dəfə də olsa, onunla əlaqə saxlamalı olacaqsınız. Bu təcrübələr məni bu məqaləni yazmağa ruhlandırdı. Təbiətdə bir çox mövcud veb xüsusiyyətləri və texnologiyaları var ki, onlara heç vaxt gündəlik işinizdə birbaşa toxuna bilməyəcəksiniz. Ola bilsin ki, siz veb-inkişafda kifayət qədər yenisiniz və sadəcə olaraq onlardan xəbərsizsiniz, çünki siz onu dərindən və ya ümumiyyətlə bilməyinizi tələb etməyən konkret çərçivənin abstraksiyasına dalmısınız. Mən xüsusilə çoxumuzun HTML-dən tamamilə fərqli olmayan qədim bir dil olduğunu bildiyimiz XML haqqında danışıram. XSLT proqramlaşdırması kimi tanınan XML yığınının əhəmiyyətli bir hissəsinin brauzerlərdən silinməsini təklif edən son WHATWG müzakirələrinə görə bunu gündəmə gətirirəm. Bu, komandamın içində olduğu CSSOM vəziyyəti kimi praktiki bir şey üçün istifadə edilə bilən illərdir əldə etdiyimiz köhnə, mövcud texnologiya növüdür. Daha əvvəl XSLT ilə işləmisiniz? Gəlin görək, biz bu köhnə texnologiyaya çox bel bağlayırıq və bu gün real dünya problemlərini həll etmək üçün onun xüsusiyyətlərindən XML kontekstindən kənarda istifadə edək. XPath: Mərkəzi API Düz XML perspektivindən kənarda bəlkə də ən faydalı olan ən mühüm XML texnologiyası, bir kök elementi olan işarələmə ağacında hər hansı node və ya atribut tapmağa imkan verən sorğu dili XPath-dir. Mənim XSLT-ə şəxsi sevgim var, lakin bu, həm də XPath-a əsaslanır və şəxsi ehtiras sıralama baxımından bir kənara qoyulmalıdır. XSLT-nin silinməsi üçün arqument XPath haqqında heç bir qeyd etmir, buna görə də buna hələ də icazə verilir. Bu yaxşıdır, çünki XPath bu texnologiyalar dəstindəki mərkəzi və ən vacib API-dir, xüsusən də normal XML istifadəsindən kənar istifadə etmək üçün nəsə tapmaq istəyərkən. Bu vacibdir, çünki CSS seçiciləri səhifənizdəki elementlərin əksəriyyətini tapmaq üçün istifadə olunsa da, onların hamısını tapa bilmirlər. Bundan əlavə, CSS seçiciləri DOM-dakı cari mövqeyinə əsaslanan elementi tapmaq üçün istifadə edilə bilməz. XPath bilər. İndi bunu oxuyanlarınızdan bəziləri XPath-ı bilə bilər, bəziləri isə bilmir. XPath texnologiyanın olduqca böyük sahəsidir və mən həqiqətən bütün əsasları öyrədə bilmirəm və eyni zamanda bu kimi bir məqalədə bununla bağlı gözəl şeylər göstərə bilmirəm. Mən əslində o məqaləni yazmağa çalışdım, lakin orta hesabla Smashing Magazine nəşri 5000 sözdən çox deyil. Mən artıq çox idi2.000 söz, əsasları yalnız yarıya qədər. Beləliklə, mən XPath ilə gözəl işlər görməyə başlayacağam və bu materialı maraqlı hesab etsəniz, əsaslar üçün istifadə edə biləcəyiniz bəzi bağlantılar verəcəyəm. XPath və CSS-ni birləşdirir XPath elementləri sorğulayarkən CSS seçicilərinin edə bilmədiyi bir çox şeyi edə bilər. Lakin CSS seçiciləri XPath-ın edə bilmədiyi bir neçə şeyi də edə bilər, yəni elementləri sinif adına görə sorğulaya bilər.
CSS XPath .myClass /*[içerir(@class, "myClass")]
Bu nümunədə, CSS .myClass sinif adını ehtiva edən elementləri sorğulayır. Bu arada, XPath nümunəsi “myClass” sətri ilə atribut sinfi olan elementləri sorğulayır. Başqa sözlə, o, hər hansı atributda myClass olan elementləri, o cümlədən .myClass sinif adı olan elementləri, həmçinin .myClass2 kimi sətirdə “myClass” olan elementləri seçir. XPath bu mənada daha genişdir. Deməli, yox. Mən təklif etmirəm ki, CSS-i silib XPath vasitəsilə bütün elementləri seçməyə başlayaq. Məsələ bu deyil. Məsələ burasındadır ki, XPath CSS-in edə bilmədiyi və hələ də çox faydalı ola bildiyi şeyləri edə bilər, baxmayaraq ki, bu brauzer yığınında köhnə texnologiyadır və ilk baxışda açıq görünməsə də. Gəlin bu iki texnologiyadan təkcə bacardığımız üçün deyil, həm də bu prosesdə XPath haqqında nəsə öyrənəcəyimizə görə istifadə edək və onu yığınınızdakı başqa bir alət halına gətirək – bəlkə də, əvvəllər orada olduğunu bilmədiyin! Problem ondadır ki, JavaScript-in document.evaluate metodu və JavaScript üçün CSS API-ləri ilə istifadə etdiyimiz müxtəlif sorğu seçici üsulları uyğun gəlmir. Bizi işə başlamaq üçün uyğun sorğu API yaratdım, amma etiraf etmək lazımdır ki, burada gördüyümüz işdən uzaqlaşdığı üçün bu barədə çox fikirləşməmişəm. Budur təkrar istifadə edilə bilən sorğu konstruktorunun olduqca sadə iş nümunəsi: Bryan Rasmussenin qələm sorğusuna XPath [forked] baxın. Sənəd obyektinə iki üsul əlavə etdim: queryCSSSelectors (bu, mahiyyətcə querySelectorAll) və queryXPaths. Bunların hər ikisi queryResults obyektini qaytarır:
{ sorğu növü: qovşaqlar | simli | sayı | boolean, nəticələr: hər hansı [] // html elementləri, xml elementləri, sətirlər, rəqəmlər, mantiq, queryCSSSelectors: (sorğu: sətir, düzəliş: boolean) => queryResults, queryXpaths: (sorğu: sətir, düzəliş: boolean) => queryResults }
QueryCSSSelectors və queryXpaths funksiyaları, əlbəttə ki, nəticələr massivi qovşaq tipli olduğu müddətcə onlara verdiyiniz sorğunu nəticələr massivindəki elementlər üzərində yerinə yetirir. Əks halda, o, boş massiv və qovşaq növü ilə queryResult qaytaracaq. Dəyişiklik xüsusiyyəti doğru olaraq təyin edilərsə, funksiyalar öz queryResults-lərini dəyişəcək. Heç bir halda bu, istehsal mühitində istifadə edilməməlidir. Mən bunu sırf iki sorğu API-nin birlikdə istifadəsinin müxtəlif effektlərini nümayiş etdirmək üçün edirəm. Nümunə sorğular Mən edə biləcəkləri güclü işlərin bəzilərini və digər yanaşmaların yerinə necə istifadə oluna biləcəyini nümayiş etdirən müxtəlif XPath sorğularından bir neçə nümunə göstərmək istəyirəm. Birinci misal //li/text(). Bu, bütün li elementlərini sorğulayır və onların mətn qovşaqlarını qaytarır. Beləliklə, əgər aşağıdakı HTML-ni sorğulasaq:
- bir
- iki
- üç
… qaytarılan budur:
{"queryType":"xpathEvaluate","results":["bir","iki","üç"],"resultType":"string"}
Başqa sözlə, aşağıdakı massivi alırıq: ["bir", "iki", "üç"]. Normalda siz bunu əldə etmək üçün li elementlərinə sorğu verərdiniz, həmin sorğunun nəticəsini massivə çevirər, massivi xəritələndirər və hər bir elementin mətn qovşağını qaytarardınız. Ancaq XPath ilə bunu daha qısa şəkildə edə bilərik: document.queryXPaths("//li/text()").nəticələr.
Diqqət yetirin ki, mətn qovşağını əldə etməyin yolu funksiya imzasına bənzəyən text() funksiyasından istifadə etməkdir – və belədir. Elementin mətn qovşağını qaytarır. Bizim nümunəmizdə işarələmədə üç li elementi var, hər birində mətn ("bir", "iki" və "üç") var.
text() sorğusunun daha bir nümunəsinə baxaq. Tutaq ki, bu bizim işarələməmizdir:
href atribut dəyərini qaytaran sorğu yazaq: document.queryXPaths("//a[text() = 'Daxil ol']/@href").nəticələr.
Bu, son nümunə kimi, cari sənəddə XPath sorğusudur, lakin bu dəfə biz “Giriş” mətnini ehtiva edən linkin (elementin) href atributunu qaytarırıq. Əsl geri döndünəticə ["/login.html"]dir. XPath Funksiyalarına Baxış Bir sıra XPath funksiyaları var və yəqin ki, siz onlarla tanış deyilsiniz. Məncə, bilməyə dəyər bir neçə var, o cümlədən aşağıdakılar:
starts-withƏgər mətn konkret başqa mətn nümunəsi ilə başlayırsa, href atributu http: ilə başlayırsa starts-with(@href, 'http:') doğru qaytarır. Əgər mətndə konkret başqa mətn nümunəsi varsa, mətn qovşağında hər hansı bir yerdə “Smashing Magazine” sözləri varsa, ehtiva edir(text(), “Smashing Magazine”) doğru qaytarır. count Bir sorğuya neçə uyğunluq olduğunun sayını qaytarır. Məsələn, count(//*[starts-with(@href, 'http:']) kontekst qovşağında http: ilə başlayan mətni ehtiva edən href atributlu elementlərə malik neçə keçidin sayını qaytarır. substring JavaScript alt sətri kimi işləyir, ancaq sətri arqument kimi ötürməyiniz istisna olmaqla. Məsələn, substring("mənim mətnim", 2, 4) "y t"-ni qaytarır. substring-beforeSətrin digər sətirdən əvvəl olan hissəsini qaytarır. Məsələn, substing-befor("my text", " ") "my"-ni qaytarır. Eynilə, substring-before("hi","bye") boş sətir qaytarır. substring-afterBaşqa sətirdən sonra sətir hissəsini qaytarır. Məsələn, substing-after("mənim mətnim", " ") "mətn"i qaytarır. Eynilə, substring-after("hi","bye")boş sətri qaytarır. normalize-space Baş və arxadakı boşluqları silməklə və boşluq simvollarının ardıcıllığını tək boşluqla əvəz etməklə normallaşdırılmış boşluqla arqument sətirini qaytarır. notArqument yanlışdırsa, boolean doğrunu qaytarır, əks halda yalan. trueBoolean doğrunu qaytarır. false Boolean yalanını qaytarır. concat JavaScript concat ilə eyni şeydir, ancaq siz onu sətirdə metod kimi işlətmirsiniz. Bunun əvəzinə birləşdirmək istədiyiniz bütün sətirləri daxil edirsiniz. string-lengthBu JavaScript sətir uzunluğu ilə eyni deyil, əksinə arqument kimi verilmiş sətir uzunluğunu qaytarır. translateThis sətir götürür və ikinci arqumenti üçüncü arqumentə dəyişir. Məsələn, translate("abcdef", "abc", "XYZ") XYZdef çıxışlarını verir.
Bu xüsusi XPath funksiyalarından başqa, JavaScript analoqları ilə eyni işləyən bir sıra digər funksiyalar da var - və ya əsasən hər hansı bir proqramlaşdırma dilində olan həmkarları - yəqin ki, döşəmə, tavan, dəyirmi, cəmi və s. kimi faydalı tapa bilərsiniz. Aşağıdakı demo bu funksiyaların hər birini göstərir: Bryan Rasmussen tərəfindən Pen XPath Rəqəmsal funksiyalarına baxın. Qeyd edək ki, əksər simli manipulyasiya funksiyaları kimi, bir çox ədədi funksiyalar da tək girişi qəbul edir. Bu, əlbəttə ki, sonuncu XPath nümunəsində olduğu kimi, sorğu üçün istifadə edilməli olduğuna görədir: //li[mərtəbə(mətn()) > 250]/@val
Əgər onlardan istifadə etsəniz, əksər nümunələrdə olduğu kimi, onu yola uyğun gələn ilk qovşaqda işə salacaqsınız. Yəqin ki, qaçınmalı olduğunuz bəzi növ çevirmə funksiyaları da var, çünki JavaScript-in artıq öz növə çevirmə problemləri var. Ancaq bəzi vaxtlar ola bilər ki, siz onu başqa nömrə ilə yoxlamaq üçün sətri nömrəyə çevirmək istəyirsiniz. Bir şeyin növünü təyin edən funksiyalar boolean, nömrə, sətir və nodedur. Bunlar vacib XPath məlumat növləridir. Təsəvvür etdiyiniz kimi, bu funksiyaların əksəriyyəti DOM qovşaqları olmayan məlumat tiplərində istifadə edilə bilər. Məsələn, substring-after artıq əhatə etdiyimiz kimi bir sətir götürür, lakin bu, href atributunun sətri ola bilər. O, həmçinin sadəcə bir sətir ola bilər:
const testSubstringAfter = document.queryXPaths("substring-after('salam dünya',' ')");
Aydındır ki, bu nümunə bizə nəticələr massivini ["dünya"] olaraq geri verəcəkdir. Bunu hərəkətdə göstərmək üçün mən DOM qovşaqları olmayan şeylərə qarşı funksiyalardan istifadə edərək demo səhifə hazırladım: Bryan Rasmussenin qələm sorğusuna XPath [forked] baxın. Tərcümə funksiyasının təəccüblü cəhətini qeyd etməlisiniz, yəni ikinci arqumentdə simvolunuz varsa (yəni tərcümə etmək istədiyiniz simvolların siyahısı) və tərcümə etmək üçün uyğun simvol yoxdursa, həmin simvol çıxışdan silinir. Beləliklə, bu:
translate('Salam, mənim adım Iniqo Montoya, atamı öldürdün, ölməyə hazırlaş','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
... boşluqlar daxil olmaqla sətirdə nəticələr: [" * * ** "]
Bu o deməkdir ki, “a” hərfi ulduz işarəsinə (*) tərcümə olunur, lakin hədəf sətirdə tərcüməsi olmayan hər bir simvol tamamilə silinir. Bizdə qalan tək boşluqdurtərcümə edilmiş “a” simvolları arasında. Sonra yenə bu sorğu:
translate('Salam, Mənim Adım Iniqo Montoyadır, atamı öldürdün, ölməyə hazırlaş','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************")")
…problemi yoxdur və belə görünən nəticə verir:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Sizi təəccübləndirə bilər ki, JavaScript-də XPath tərcümə funksiyasının tam olaraq nə etdiyini etmək üçün heç bir asan yol yoxdur, baxmayaraq ki, bir çox istifadə halları üçün All'ı müntəzəm ifadələrlə əvəz edə bilər. Siz mənim nümayiş etdirdiyim eyni yanaşmadan istifadə edə bilərsiniz, ancaq sətirləri tərcümə etmək istəyirsinizsə, bu, optimal deyil. Aşağıdakı demo JavaScript versiyasını təmin etmək üçün XPath-ın tərcümə funksiyasını əhatə edir: Bryan Rasmussen tərəfindən qələmin tərcüməsi funksiyasına baxın. Belə bir şeyi harada istifadə edə bilərsiniz? Üç yerlik ofsetlə Sezar Şifrə şifrələməsini nəzərdən keçirin (məsələn, eramızdan əvvəl 48-ci ildən ən yüksək səviyyəli şifrələmə):
translate("Sezar Rubikonu keçməyi planlaşdırır!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Giriş mətni "Sezar Rubikonu keçməyi planlaşdırır!" nəticələr "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Müxtəlif imkanların başqa bir qısa nümunəsini vermək üçün mən sətir girişi qəbul edən və mətni qaytarmaq üçün tərcümə funksiyasından istifadə edən metal funksiya yaratdım, o cümlədən umlaut götürən bütün simvollar. Bryan Rasmussen tərəfindən qələm metal funksiyasına baxın.
const metal = (str) => { tərcüməni qaytarın(küç, "AOUaou","ÄÖÜäöü"); }
Və əgər “Motley Crue rules, rock on dudes!” mətni verilsə, “Mötley Crue rüles, röck ön dudes!” qaytarılır. Aydındır ki, bu funksiyadan hər cür parodiya istifadə edilə bilər. Əgər bu sizsinizsə, bu TVTropes məqaləsi sizə çoxlu ilham verməlidir. XPath ilə CSS-dən istifadə XPath ilə birlikdə CSS seçicilərindən istifadə etməyimizin əsas səbəbini xatırlayın: CSS sinfin nə olduğunu çox yaxşı başa düşür, halbuki XPath ilə edə biləcəyiniz ən yaxşı şey sinif atributunun sətir müqayisəsidir. Bu, əksər hallarda işləyəcək. Amma nə vaxtsa, məsələn, kiminsə .primaryLinks və .primaryLinks2 adlı siniflər yaratdığı və .primaryLinks sinfini əldə etmək üçün XPath-dan istifadə etdiyiniz vəziyyətlə qarşılaşsanız, çox güman ki, problemlərlə üzləşəcəksiniz. Nə qədər ki, belə axmaq bir şey yoxdur, yəqin ki, XPath-dan istifadə edərdiniz. Ancaq insanların bu cür axmaq şeylər etdiyi yerlərdə işlədiyimi bildirməkdən kədərlənirəm. Budur CSS və XPath-dan birlikdə istifadə edən başqa bir demo. Sənədin qovşağı olmayan kontekst qovşağında XPath-ı işə salmaq üçün koddan istifadə etdiyimiz zaman nə baş verdiyini göstərir. Bryan Rasmussen tərəfindən [forked] Pen css və xpath-a birlikdə baxın. CSS sorğusu .relatedarticles a-dır ki, bu da .relatedarticles sinfinə təyin edilmiş div-də iki a elementini alır. Bundan sonra üç “pis” sorğu, yəni kontekst qovşağı kimi bu elementlərlə işləyərkən bizim istədiklərimizi etməyən sorğulardır. Onların niyə gözlədiyinizdən fərqli davrandıqlarını izah edə bilərəm. Sözügedən üç pis sorğu bunlardır:
//text(): Sənəddəki bütün mətni qaytarır. //a/text(): Sənəddəki keçidlərin daxilindəki bütün mətni qaytarır. ./a/text(): Heç bir nəticə vermir.
Bu nəticələrin səbəbi odur ki, kontekstiniz CSS sorğusundan qaytarılmış elementlər olsa da, // bütün sənədə ziddir. Bu XPath-ın gücüdür; CSS bir qovşaqdan əcdadına, sonra isə həmin əcdadın bacısına keçə bilməz və bu qardaşın nəslinə gedə bilməz. Ancaq XPath edə bilər. Eyni zamanda, ./ cari qovşağın uşaqlarını sorğulayır, burada nöqtə (.) cari qovşağı təmsil edir və əyri xətt (/) hansısa uşaq qovşağına getməyi təmsil edir - onun atribut, element və ya mətn olub-olmaması yolun növbəti hissəsi ilə müəyyən edilir. Lakin CSS sorğusu ilə seçilmiş element uşaq yoxdur, beləliklə, bu sorğu da heç nə qaytarmır. Son demoda üç yaxşı sorğu var:
.//mətn(), ./text(), normallaşdırmaq-boşluq(./text()).
Normalize-space sorğusu XPath funksiyasından istifadəni nümayiş etdirir, həm də digər sorğulara daxil olan problemi həll edir. HTML aşağıdakı kimi qurulmuşdur:
Selenium WebDriver ilə Xüsusiyyət Testinizi avtomatlaşdırın
Sorğu mətn qovşağının əvvəlində və sonunda sətir axını qaytarır,və normalize-space bunu aradan qaldırır. XPath girişi ilə booleandan başqa bir şey qaytaran hər hansı XPath funksiyasından istifadə digər funksiyalara aiddir. Aşağıdakı demo bir sıra nümunələri göstərir: Bryan Rasmussenin [forked] Pen xpath funksiyalarına baxın. Birinci nümunə diqqət etməli olduğunuz problemi göstərir. Xüsusilə, aşağıdakı kod:
document.queryXPaths("alt sətirdən sonra(//a/@href,'https://')");
…bir sətri qaytarır:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Məntiqlidir, elə deyilmi? Bu funksiyalar massivləri deyil, tək sətirləri və ya tək ədədləri qaytarır. Funksiyanı çoxlu nəticə ilə istənilən yerdə işə salmaq yalnız ilk nəticəni qaytarır. İkinci nəticə həqiqətən nə istədiyimizi göstərir:
document.queryCSSSelectors("a").queryXPaths("alt sətirdən sonra(./@href,'https://')");
Hansı ki, iki sətirdən ibarət massiv qaytarır:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath funksiyaları JavaScript-dəki funksiyalar kimi yuvalana bilər. Beləliklə, Smashing Magazine URL strukturunu bilsək, aşağıdakıları edə bilərik (şablon literallarından istifadə etmək tövsiyə olunur): `tərcümə et( alt sətir ( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Bu, nə etdiyini izah edən şərhlərə ehtiyac duyduğu dərəcədə bir qədər mürəkkəbləşir: www.smashingmagazine.com/-dan sonra href atributundan URL-in hamısını götürün, ilk doqquz simvolu silin, sonra slash (/) simvolunu heç bir yerə tərcümə edin ki, bitən kəsik xəttindən xilas olasınız. Nəticə massiv:
["feature-testing-selenium-webdriver","avtomatlaşdırılmış-test nəticələri-əlçatanlığı yaxşılaşdır"]
Daha çox XPath İstifadəsi halları XPath həqiqətən sınaqda parlaya bilər. Səbəbini görmək çətin deyil, çünki XPath DOM-dakı hər bir elementi DOM-un istənilən mövqeyindən əldə etmək üçün istifadə edilə bilər, CSS isə bunu edə bilməz. Bir çox müasir qurma sistemlərində ardıcıl olaraq qalan CSS siniflərinə arxalana bilməzsiniz, lakin XPath ilə dəyişən DOM strukturundan asılı olmayaraq elementin mətn məzmununun nə olduğu ilə bağlı daha etibarlı uyğunluqlar edə bilirik. Dayanıqlı XPath testləri etməyə imkan verən texnikalar üzərində araşdırmalar aparılmışdır. Nəyinsə adı dəyişdirildiyi və ya silindiyi üçün CSS selektoru artıq işləmədiyi üçün testlərin sıradan çıxması və uğursuz olmasından daha pis bir şey yoxdur. XPath çoxlu lokatorun çıxarılmasında da əladır. Bir elementə uyğun gəlmək üçün XPath sorğularından istifadə etməyin birdən çox yolu var. Eyni şey CSS ilə də keçərlidir. Lakin XPath sorğuları bir neçə mümkün uyğunluğun ola biləcəyi konkret uyğunluğu tapmağa imkan verən qaytarılanları məhdudlaşdıran daha məqsədyönlü şəkildə şeyləri araşdıra bilər. Məsələn, biz div daxilində olan və öz növbəsində data-testID="lider" atributuna malik uşaq şəkil elementini ehtiva edən div-dən dərhal sonra gələn xüsusi h2 elementini qaytarmaq üçün XPath-dan istifadə edə bilərik:
bu başlığı almayın
Bu başlığı da almayın
Lider şəklinin başlığı
Bu sorğudur: document.queryXPaths(` //div[ aşağıdakı qardaş ::div[1] /img[@data-testID='lider'] ] /h2/ mətn() `);
Bütün bunların necə birləşdiyini görmək üçün bir demoya baxaq: Bryan Rasmussen tərəfindən Qələm Kompleksi H2 Sorğusuna baxın. Deməli, bəli. XPath istifadə edərək testdə hər hansı elementə çoxlu mümkün yollar var. XSLT 1.0 köhnəlməsi Əvvəlcədən qeyd etdim ki, Chrome komandası XSLT 1.0 dəstəyini brauzerdən silməyi planlaşdırır. Bu vacibdir, çünki XSLT 1.0 sənədlərin dəyişdirilməsi üçün XML mərkəzli proqramlaşdırmadan istifadə edir ki, bu da öz növbəsində əksər brauzerlərdə tapılan XPath 1.0-a əsaslanır. Bu baş verdikdə, XPath-ın əsas komponentini itirəcəyik. Ancaq XPath-ın testlər yazmaq üçün həqiqətən əla olduğunu nəzərə alsaq, XPath-ın bütövlükdə tezliklə yox olacağını düşünürəm. Bununla belə, insanların bir xüsusiyyət götürüldükdə maraqlandığını gördüm. XSLT 1.0-ın köhnəlməsi halında bu, əlbəttə ki, doğrudur. Hacker News-da köhnəlməyə qarşı arqumentlərlə dolu bir müzakirə gedir. Yazının özü XSLT ilə blog çərçivəsi yaratmağın gözəl nümunəsidir. sənMüzakirəni özünüz oxuya bilərsiniz, lakin bu, JavaScript-in XLST üçün bu cür işlərin öhdəsindən gəlmək üçün necə istifadə oluna biləcəyini öyrənir. Brauzerlərin JavaScript-in Saxon XSLT, XQUERY və XPath mühərrikləri üçün port olan SaxonJS-dən istifadə etmələri ilə bağlı təklifləri də görmüşəm. Bu maraqlı fikirdir, xüsusən də Saxon-JS bu spesifikasiyaların cari versiyasını tətbiq edir, halbuki 1.0-dan yuxarı XPath və ya XSLT-nin hər hansı bir versiyasını tətbiq edən brauzer yoxdur və XQuery-ni tətbiq edən heç biri yoxdur. SaxonJS və Saxon mühərrikinin digər versiyalarının arxasında duran şirkət olan Saxonikada Norm Tovey-Walsh ilə əlaqə saxladım. O dedi: "Əgər hər hansı bir brauzer satıcısı SaxonJS-ni müasir XML texnologiyalarını brauzerə inteqrasiya etmək üçün başlanğıc nöqtəsi kimi götürməkdə maraqlı olsaydı, biz onlarla bunu müzakirə etməkdən məmnun olarıq." - Norm Tovey-Walsh
Ancaq əlavə etdi: "Kimsə SaxonJS-ni indiki formada götürüb onu dəyişmədən brauzer quruluşuna buraxmağın ideal yanaşma olacağını düşünsə, çox təəccüblənərdim. Brauzer satıcısı, brauzeri qurduqlarına görə, inteqrasiyaya bizim "kənardan" baxa biləcəyimizdən daha dərin səviyyədə yanaşa bilər." - Norm Tovey-Walsh
Qeyd etmək lazımdır ki, Tovey-Walsh-ın şərhləri XSLT-nin ləğvi elanından təxminən bir həftə əvvəl gəldi. Nəticə Mən davam edə bilərdim. Ancaq ümid edirəm ki, bu XPath-ın gücünü nümayiş etdirdi və böyük şeylərə nail olmaq üçün ondan necə istifadə olunacağını göstərən çoxlu nümunələr verdi. Bu, mövcud olduğunu heç vaxt bilmədiyiniz və ya heç vaxt ona çatmağı düşünmədiyiniz halda, bu gün hələ də çox faydalı olan brauzer yığınında köhnə texnologiyanın mükəmməl nümunəsidir. Əlavə Oxu
Maroun Ayli, Youssef Bakouny, Nader Calloul və Rima Kilany tərəfindən "Təbii Dillə Avtomatlaşdırılmış Veb Testlərinin Dayanıqlığının Artırılması" (ACM Rəqəmsal Kitabxanası) Bu məqalə davamlı testlərin yazılması üçün çoxlu XPath nümunələri təqdim edir. XPath (MDN) XPath-ın necə işlədiyini izah edən texniki izahat istəyirsinizsə, bu, başlamaq üçün əla yerdir. XPath Təlimatı (ZVON) Çoxlu nümunələr və aydın izahatlar sayəsində bu dərsliyi öz öyrənməmdə ən faydalı olduğunu gördüm. XPatherBu interaktiv alət sizə birbaşa kodla işləməyə imkan verir.
