Я займаюся інтэрфейснай распрацоўкай дастаткова доўга, каб заўважыць тэндэнцыю на працягу многіх гадоў: маладыя распрацоўшчыкі працуюць з новай парадыгмай праграмавання, не разумеючы яе гістарычнага кантэксту. Не ведаць чагосьці, вядома, цалкам зразумела. Інтэрнэт - гэта вельмі вялікае месца з разнастайным наборам навыкаў і спецыяльнасцей, і мы не заўсёды ведаем, чаго не ведаем. Навучанне ў гэтай галіне - гэта працяглае падарожжа, а не тое, што адбываецца адзін раз і заканчваецца. Прыклад: нехта з маёй каманды спытаў, ці можна вызначыць, калі карыстальнікі адыходзяць ад пэўнай укладкі ў карыстальніцкім інтэрфейсе. Я адзначыў падзею JavaScript beforeunload. Але тыя, хто займаўся гэтым раней, ведаюць, што гэта магчыма, таму што яны атрымлівалі абвесткі аб незахаваных дадзеных на іншых сайтах, для якіх beforeunload з'яўляецца тыповым варыянтам выкарыстання. Я таксама паказаў свайму калегу падзеі pageHide і visibilityChange для добрай меры. Адкуль я пра гэта даведаўся? Таму што гэта з'явілася ў іншым праекце, а не таму, што я вывучаў яго, калі першапачаткова вывучаў JavaScript. Справа ў тым, што сучасныя інтэрфейсныя фрэймворкі стаяць на плячах тэхналагічных гігантаў, якія ім папярэднічалі. Яны абстрагуюцца ад практыкі распрацоўкі, часта для лепшага вопыту распрацоўніка, які памяншае або нават пазбаўляе ад неабходнасці ведаць або дакранацца да таго, што традыцыйна з'яўлялася важнымі канцэпцыямі інтэрфейсу, якія, верагодна, павінен ведаць кожны. Разгледзім аб'ектную мадэль 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 можна выкарыстоўваць для пошуку большасці элементаў на вашай старонцы, але яны не могуць знайсці іх усе. Акрамя таго, селектары CSS нельга выкарыстоўваць для пошуку элемента на аснове яго бягучага становішча ў DOM. XPath можа. Некаторыя з вас, хто чытае гэта, могуць ведаць XPath, а некаторыя - не. XPath - гэта даволі шырокая вобласць тэхналогій, і я не магу навучыць усім асновам, а таксама паказаць вам цікавыя рэчы, якія можна з ёй зрабіць, у адным падобным артыкуле. Я сапраўды спрабаваў напісаць гэты артыкул, але сярэдняя публікацыя Smashing Magazine не перавышае 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 у працэсе, зрабіўшы яго яшчэ адным інструментам у вашым стэку - той, пра які вы, магчыма, не ведалі, што існуе ўвесь час! Праблема ў тым, што метад JavaScript document.evaluate і розныя метады селектара запытаў, якія мы выкарыстоўваем з CSS API для JavaScript, несумяшчальныя. Каб пачаць, я стварыў сумяшчальны API для запытаў, хаця, трэба прызнаць, я не надта задумваўся над гэтым, бо гэта адхіленне ад таго, што мы тут робім. Вось даволі просты працоўны прыклад шматразовага канструктара запытаў: Глядзіце Pen queryXPath [forked] Браяна Расмусэна. Я дадаў два метады да аб'екта дакумента: queryCSSSelectors (які па сутнасці з'яўляецца querySelectorAll) і queryXPaths. Абодва вяртаюць аб'ект queryResults:
{ queryType: вузлы | радок | нумар | лагічны, вынікі: любы [] // элементы html, элементы xml, радкі, лічбы, лагічныя значэнні, queryCSSSelectors: (запыт: радок, змяненне: лагічны) => queryResults, queryXpaths: (запыт: радок, змяненне: лагічны) => queryResults }
Функцыі queryCSSSelectors і 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:') вяртае true, калі атрыбут href пачынаецца з http:. containsКалі тэкст утрымлівае канкрэтны іншы тэкст, напрыклад, contains(text(), "Smashing Magazine") вяртае ісціну, калі тэкставы вузел змяшчае ў сабе словы "Smashing Magazine". count Вяртае колькасць супадзенняў з запытам. Напрыклад, count(//*[starts-with(@href, 'http:']) вяртае падлік таго, колькі спасылак у кантэкстным вузле маюць элементы з атрыбутам href, які змяшчае тэкст, які пачынаецца з http:. substringПрацуе як падрадок JavaScript, за выключэннем таго, што вы перадаеце радок як аргумент. Напрыклад, падрадок("мой тэкст", 2, 4) вяртае "y t". substring-before Вяртае частку радка перад іншым радком. Напрыклад, substing-before("мой тэкст", " ") вяртае "мой". Аналагічным чынам substring-before("hi","bye") вяртае пусты радок. substring-afterВяртае частку радка пасля іншага радка. Напрыклад, substing-after("мой тэкст", " ") вяртае "тэкст". Аналагічным чынам substring-after("hi","bye") вяртае пусты радок. normalize-space Вяртае радок аргументаў з прабеламі, нармалізаванымі выдаленнем прабелаў у пачатку і ў канцы і заменай паслядоўнасці прабелаў на адзін прабел. notВяртае лагічнае значэнне true, калі аргумент false, у адваротным выпадку false. true Вяртае лагічнае значэнне true. false Вяртае лагічнае значэнне false. concat Тое ж самае, што і JavaScript concat, за выключэннем таго, што вы не запускаеце яго як метад у радку. Замест гэтага вы змяшчаеце ўсе радкі, якія хочаце аб'яднаць. string-lengthГэта не тое ж самае, што JavaScript string-length, а хутчэй вяртае даўжыню радка, якую ён даў у якасці аргумента. translateThis прымае радок і змяняе другі аргумент на трэці. Напрыклад, translate("abcdef", "abc", "XYZ") выводзіць XYZdef.
Акрамя гэтых пэўных функцый XPath, ёсць шэраг іншых функцый, якія працуюць гэтак жа, як і іх аналагі JavaScript — або аналагі практычна любой мовы праграмавання — якія вы, верагодна, таксама знойдзеце карыснымі, напрыклад, падлогу, столь, раунд, суму і гэтак далей. Наступная дэманстрацыя ілюструе кожную з гэтых функцый: Глядзіце лікавыя функцыі Pen XPath [разгалінаваныя] Браяна Расмусэна. Звярніце ўвагу, што, як і большасць функцый апрацоўкі радкоў, многія з лікавых прымаюць адзін увод. Гэта, вядома, таму, што яны павінны выкарыстоўвацца для запытаў, як у апошнім прыкладзе XPath: //li[floor(text()) > 250]/@val
Калі вы выкарыстоўваеце іх, як у большасці прыкладаў, вы ў выніку запусціце яго на першым вузле, які адпавядае шляху. Ёсць таксама некаторыя функцыі пераўтварэння тыпаў, якіх вам варта пазбягаць, таму што ў JavaScript ужо ёсць свае праблемы з пераўтварэннем тыпаў. Але могуць быць моманты, калі вы захочаце пераўтварыць радок у лік, каб праверыць яго з іншым лікам. Функцыі, якія задаюць тып чаго-небудзь, - гэта лагічны, лік, радок і вузел. Гэта важныя тыпы дадзеных XPath. І як вы маглі сабе ўявіць, большасць з гэтых функцый можна выкарыстоўваць для тыпаў даных, якія не з'яўляюцца вузламі DOM. Напрыклад, substring-after прымае радок, як мы ўжо разглядалі, але гэта можа быць радок з атрыбуту href. Гэта таксама можа быць проста радок:
const testSubstringAfter = document.queryXPaths("substring-after('прывітанне, свет',' ')");
Відавочна, што гэты прыклад верне нам масіў вынікаў як ["свет"]. Каб паказаць гэта ў дзеянні, я зрабіў дэма-старонку з выкарыстаннем функцый супраць рэчаў, якія не з'яўляюцца вузламі DOM: Глядзіце Pen queryXPath [forked] Браяна Расмусэна. Вы павінны звярнуць увагу на дзіўны аспект функцыі перакладу, які заключаецца ў тым, што калі ў вас ёсць сімвал у другім аргументе (г.зн. спіс сімвалаў, якія вы хочаце перакласці) і няма адпаведнага сімвала для перакладу, гэты сімвал выдаляецца з вываду. Такім чынам, гэта:
translate('Прывітанне, мяне завуць Ініга Мантоя, ты забіў майго бацьку, рыхтуйся да смерці','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
... вынікі ў радку, уключаючы прабелы: [" * * ** "]
Гэта азначае, што літара «a» перакладаецца ў зорачку (*), але ўсе астатнія сімвалы, якія не маюць перакладу ў мэтавым радку, цалкам выдаляюцца. Прабелы - усё, што нам засталосяпаміж перакладзенымі знакамі «а». Зноў жа, гэты запыт:
translate('Прывітанне, мяне завуць Ініга Мантоя, ты забіў майго бацьку, рыхтуйся да смерці','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','************************************************************')")
...няма праблемы і выдае вынік, які выглядае так:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Вам можа здацца, што ў JavaScript няма простага спосабу зрабіць менавіта тое, што робіць функцыя перакладу XPath, хаця ў многіх выпадках выкарыстання replaceAll з рэгулярнымі выразамі можа справіцца з гэтым. Вы можаце выкарыстоўваць той самы падыход, які я прадэманстраваў, але гэта неаптымальна, калі ўсё, што вы хочаце, гэта перавесці радкі. Наступная дэманстрацыя абгортвае функцыю перакладу XPath, каб забяспечыць версію JavaScript: Глядзіце функцыю перакладу Pen [forked] Браяна Расмусэна. Дзе вы можаце выкарыстоўваць нешта падобнае? Разгледзім шыфраванне Caesar Cipher са зрушэннем у тры знака (напрыклад, шыфраванне верхняй лініі з 48 г. да н. э.):
translate("Цэзар плануе перайсці Рубікон!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Уваходны тэкст «Цэзар плануе перайсці Рубікон!» вынікі ў «Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!» Каб прывесці яшчэ адзін кароткі прыклад розных магчымасцей, я стварыў металічную функцыю, якая прымае радковы ўвод і выкарыстоўвае функцыю перакладу для вяртання тэксту, уключаючы ўсе сімвалы, якія прымаюць умлауты. Глядзіце металічную функцыю ручкі [форк] Браяна Расмусэна.
const metal = (str) => { return translate(str, "AOUaou", "ÄÖÜäöü"); }
І, калі дадзены тэкст «Motley Crüe rules, 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 на кантэкстным вузле, які не з'яўляецца вузлом дакумента. Глядзіце Pen css і xpath разам [разгалінаваны] Браяна Расмусэна. CSS-запыт - гэта .relatedarticles a, які атрымлівае два элементы a ў div, якому прызначаны клас .relatedarticles. Пасля гэтага ідуць тры «дрэнныя» запыты, гэта значыць запыты, якія не выконваюць тое, што мы хочам, каб яны рабілі пры працы з гэтымі элементамі ў якасці кантэкстнага вузла. Я магу растлумачыць, чаму яны паводзяць сябе не так, як вы маглі чакаць. Тры дрэнныя запыты:
//text(): Вяртае ўвесь тэкст у дакуменце. //a/text(): Вяртае ўвесь тэкст унутры спасылак у дакуменце. ./a/text(): не вяртае вынікаў.
Прычына такіх вынікаў заключаецца ў тым, што, хоць ваш кантэкст з'яўляецца элементам, вернутым з запыту CSS, // супярэчыць усяму дакументу. У гэтым моцны бок XPath; CSS не можа перайсці ад вузла да продка, а затым да брата гэтага продка і перайсці да нашчадка гэтага брата. Але XPath можа. Тым часам ./ запытвае даччыных вузлоў бягучага вузла, дзе кропка (.) азначае бягучы вузел, а косая рыса (/) азначае пераход да нейкага даччынага вузла — атрыбут, элемент або тэкст вызначаецца наступнай часткай шляху. Але няма даччынага элемента, выбранага з дапамогай запыту CSS, таму гэты запыт таксама нічога не вяртае. У гэтай апошняй дэманстрацыі ёсць тры добрыя запыты:
.//тэкст(), ./тэкст(), normalize-space(./text()).
Запыт normalize-space дэманструе выкарыстанне функцыі XPath, але таксама выпраўляе праблему, уключаную ў іншыя запыты. HTML структураваны так:
Аўтаматызацыя тэсціравання вашых функцый з дапамогай Selenium WebDriver
Запыт вяртае перавод радка ў пачатку і ў канцы тэкставага вузла,і normalize-space выдаляе гэта. Выкарыстанне любой функцыі XPath, якая вяртае нешта, акрамя лагічнага значэння, з уводам XPath прымяняецца да іншых функцый. Наступная дэманстрацыя паказвае некалькі прыкладаў: Глядзіце прыклады функцый Pen xpath [forked] Браяна Расмусэна. Першы прыклад паказвае праблему, на якую варта звярнуць увагу. У прыватнасці, наступны код:
document.queryXPaths("падрадок-пасля(//a/@href,'https://')");
... вяртае адзін радок:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Гэта мае сэнс, праўда? Гэтыя функцыі вяртаюць не масівы, а адзінкавыя радкі або адзінкавыя лічбы. Запуск функцыі ў любым месцы з некалькімі вынікамі вяртае толькі першы вынік. Другі вынік паказвае, чаго мы сапраўды хочам:
document.queryCSSSelectors("a").queryXPaths("падрадок-пасля(./@href,'https://')");
Які вяртае масіў з двух радкоў:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Функцыі XPath могуць быць укладзеныя, як і функцыі ў JavaScript. Такім чынам, калі мы ведаем структуру URL Smashing Magazine, мы можам зрабіць наступнае (рэкамендуецца выкарыстоўваць літаралы шаблону): `перакласці( падрадок( падрадок-пасля(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Гэта становіцца занадта складаным да такой ступені, што патрэбныя каментарыі з апісаннем таго, што ён робіць: вазьміце ўвесь URL з атрыбута href пасля www.smashingmagazine.com/, выдаліце першыя дзевяць сімвалаў, затым перавядзіце сімвал касой рысы (/) у нішто, каб пазбавіцца ад канчатковай касой рысы. Атрыманы масіў:
["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='лідэр'] ] /h2/ тэкст() `);
Давайце паглядзім дэманстрацыю, каб убачыць, як усё гэта спалучаецца: Глядзіце запыт Pen Complex H2 [раздвоены] Браяна Расмусэна. Значыць, так. Ёсць шмат магчымых шляхоў да любога элемента ў тэсце з выкарыстаннем XPath. XSLT 1.0 састарэла Раней я згадваў, што каманда Chrome плануе выдаліць падтрымку XSLT 1.0 з браўзера. Гэта важна, таму што XSLT 1.0 выкарыстоўвае арыентаванае на XML праграмаванне для трансфармацыі дакумента, якое, у сваю чаргу, абапіраецца на XPath 1.0, які ёсць у большасці браўзераў. Калі гэта адбудзецца, мы страцім ключавы кампанент XPath. Але ўлічваючы той факт, што XPath сапраўды выдатна падыходзіць для напісання тэстаў, я лічу малаверагодным, што XPath у цэлым знікне ў бліжэйшы час. Тым не менш, я заўважыў, што людзі цікавяцца функцыяй, калі яе адмяняюць. І гэта, безумоўна, дакладна ў выпадку састарэння XSLT 1.0. У Hacker News адбываецца цэлая дыскусія, напоўненая аргументамі супраць адмены. Сама публікацыя з'яўляецца выдатным прыкладам стварэння структуры блога з XSLT. Выможаце самі прачытаць абмеркаванне, але яно даходзіць да таго, як JavaScript можа выкарыстоўвацца ў якасці ашалёўкі для XLST для апрацоўкі такіх выпадкаў. Я таксама бачыў прапановы, што браўзеры павінны выкарыстоўваць SaxonJS, які з'яўляецца портам для рухавікоў Saxon XSLT, XQUERY і XPath JavaScript. Гэта цікавая ідэя, тым больш, што Saxon-JS рэалізуе бягучую версію гэтых спецыфікацый, у той час як няма ніводнага браўзера, які рэалізуе любую версію XPath або XSLT пасля 1.0, і ніводнага, які рэалізуе XQuery. Я звярнуўся да Норма Тові-Уолша ў Saxonica, кампаніі, якая стаіць за SaxonJS і іншымі версіямі рухавіка Saxon. Ён сказаў: «Калі б які-небудзь пастаўшчык браўзераў быў зацікаўлены ў выкарыстанні SaxonJS у якасці адпраўной кропкі для інтэграцыі сучасных тэхналогій XML у браўзер, мы былі б рады абмеркаваць гэта з імі», — Норм Тові-Уолш.
Але таксама дадаў: "Я быў бы вельмі здзіўлены, калі б хто-небудзь падумаў, што ўзяць SaxonJS у яго цяперашняй форме і ўключыць яго ў зборку браўзера без зменаў было б ідэальным падыходам. Пастаўшчык браўзера, у сілу таго факту, што ён стварае браўзер, можа падысці да інтэграцыі на значна больш глыбокім узроўні, чым мы можам "звонку"" - Норм Тові-Уолш.
Варта адзначыць, што каментары Тові-Уолша былі зроблены прыкладна за тыдзень да аб'явы аб спыненні падтрымкі XSLT. Заключэнне Я мог бы працягваць і працягваць. Але я спадзяюся, што гэта прадэманстравала моц XPath і дало вам шмат прыкладаў, якія дэманструюць, як выкарыстоўваць яго для дасягнення вялікіх поспехаў. Гэта выдатны прыклад старой тэхналогіі ў стэку браўзераў, якая па-ранейшаму мае шмат карыснасці, нават калі вы ніколі не ведалі пра яе існаванне або ніколі не думалі скарыстацца ёй. Далейшае чытанне
«Павышэнне ўстойлівасці аўтаматызаваных вэб-тэстаў з натуральнай мовай» (Лічбавая бібліятэка ACM) Марун Айлі, Юсеф Бакуні, Надэр Джалул і Рыма Кілані. У гэтым артыкуле прыводзіцца мноства прыкладаў XPath для напісання ўстойлівых тэстаў. XPath (MDN) Гэта выдатнае месца для пачатку, калі вы хочаце атрымаць тэхнічнае тлумачэнне, у якім падрабязна апісваецца, як працуе XPath. Падручнік па XPath (ZVON) Я знайшоў гэты падручнік найбольш карысным у маім навучанні, дзякуючы вялікай колькасці прыкладаў і зразумелых тлумачэнняў. XPather Гэты інтэрактыўны інструмент дазваляе працаваць непасрэдна з кодам.
