Byl jsem ve vývoji frontendu dost dlouho na to, abych v průběhu let viděl trend: mladší vývojáři pracují s novým paradigmatem programování, aniž by chápali jeho historický kontext. Je samozřejmě naprosto pochopitelné, že něco nevím. Web je velmi velké místo s rozmanitou sadou dovedností a specialit a ne vždy víme, co nevíme. Učení v této oblasti je spíše pokračující cesta než něco, co se jednou stane a skončí. Příklad: Někdo z mého týmu se zeptal, zda je možné zjistit, zda uživatelé odcházejí z konkrétní karty v uživatelském rozhraní. Poukázal jsem na událost JavaScriptu beforeunload. Ale ti, kteří to řešili dříve, vědí, že je to možné, protože byli zasaženi upozorněními na neuložená data na jiných webech, pro které je typickým případem použití před uvolněním. Kolegu jsem pro jistotu upozornil i na stránkuSkrýt a viditelnostZměnit události. Jak jsem o tom věděl? Protože to přišlo v jiném projektu, ne proto, že jsem to studoval, když jsem se zpočátku učil JavaScript. Faktem je, že moderní front-end frameworky stojí na bedrech technologických gigantů, kteří jim předcházeli. Abstrahují vývojové postupy, často pro lepší vývojářskou zkušenost, která redukuje nebo dokonce eliminuje potřebu znát nebo dotýkat se toho, co byly tradičně zásadní front-endové koncepty, které by každý pravděpodobně měl znát. Zvažte objektový model CSS (CSOM). Můžete očekávat, že každý, kdo pracuje v CSS a JavaScript, má spoustu praktických zkušeností s CSSOM, ale ne vždy tomu tak bude. Pracoval jsem na projektu React pro web elektronického obchodu, kde jsme potřebovali načíst šablonu stylů pro aktuálně vybraného poskytovatele plateb. Problém byl v tom, že šablona stylů se načítala na každé stránce, když byla opravdu potřeba jen na konkrétní stránce. Vývojář, který měl za úkol toto provést, nikdy nenačítal šablonu stylů dynamicky. Opět je to zcela pochopitelné, když React abstrahuje tradiční přístup, po kterém jste možná sáhli. CSSOM pravděpodobně není něco, co potřebujete ve své každodenní práci. Ale je pravděpodobné, že s ním budete muset v určitém okamžiku komunikovat, a to i v jednorázovém případě. Tyto zkušenosti mě inspirovaly k napsání tohoto článku. Ve volné přírodě existuje mnoho existujících webových funkcí a technologií, kterých se ve své každodenní práci možná nikdy nedotknete. Možná jste ve vývoji webu poměrně nováčci a jednoduše o nich nevíte, protože jste ponořeni do abstrakce specifického rámce, který nevyžaduje, abyste jej znali hluboce nebo dokonce vůbec. Mluvím konkrétně o XML, o kterém mnozí z nás ví, že je to prastarý jazyk, který není úplně nepodobný HTML. Uvádím to kvůli nedávným diskusím WHATWG, které naznačují, že by měla být z prohlížečů odstraněna významná část zásobníku XML známého jako programování XSLT. Toto je přesně ten druh starší existující technologie, kterou máme léta a kterou lze použít pro něco tak praktického, jako je situace CSSOM, ve které se můj tým nacházel. Pracovali jste již s XSLT? Podívejme se, zda se do této starší technologie výrazně opřeme a využijeme její funkce mimo kontext XML k řešení skutečných problémů dneška. XPath: Centrální API Nejdůležitější technologií XML, která je možná nejužitečnější mimo přímou perspektivu XML, je XPath, dotazovací jazyk, který vám umožňuje najít jakýkoli uzel nebo atribut ve stromu značek s jedním kořenovým prvkem. Mám osobní náklonnost k XSLT, ale to také závisí na XPath a osobní náklonnost musí být v žebříčku důležitosti odložena stranou. Argument pro odstranění XSLT nezmiňuje XPath, takže předpokládám, že je stále povolen. To je dobře, protože XPath je centrální a nejdůležitější API v této sadě technologií, zvláště když se snažíte najít něco, co by se dalo použít mimo běžné použití XML. Je to důležité, protože zatímco selektory CSS lze použít k nalezení většiny prvků na stránce, nemohou je najít všechny. Selektor CSS navíc nelze použít k nalezení prvku na základě jeho aktuální pozice v DOM. XPath může. Někteří z vás, kteří to čtete, možná znáte XPath a někteří ne. XPath je poměrně rozsáhlá oblast technologie a v jediném článku, jako je tento, nemohu skutečně naučit všechny základy a také vám ukázat skvělé věci, které s tím lze dělat. Vlastně jsem se pokusil napsat ten článek, ale průměrná publikace Smashing Magazine nepřesahuje 5 000 slov. Už jsem byl na více než2000 slov a přitom jen v polovině základů. Takže začnu dělat skvělé věci s XPath a dám vám několik odkazů, které můžete použít pro základy, pokud vás tyto věci budou zajímat. Kombinace XPath a CSS XPath umí spoustu věcí, které selektory CSS při dotazování prvků neumí. Selektory CSS však mohou také dělat několik věcí, které XPath neumí, konkrétně dotazovat prvky podle názvu třídy.
CSS XPath .myClass /*[contains(@class, "myClass")]
V tomto příkladu se CSS dotazuje na prvky, které obsahují název třídy .myClass. Mezitím příklad XPath dotazuje prvky, které obsahují třídu atributů s řetězcem „myClass“. Jinými slovy, vybere prvky s myClass v libovolném atributu, včetně prvků s názvem třídy .myClass — stejně jako prvky s „myClass“ v řetězci, jako je .myClass2. XPath je v tomto smyslu širší. Takže ne. Nenavrhuji, že bychom měli vyhodit CSS a začít vybírat všechny prvky přes XPath. O to nejde. Jde o to, že XPath umí věci, které CSS neumí a stále by mohly být velmi užitečné, i když se jedná o starší technologii v zásobníku prohlížeče a na první pohled se nemusí zdát samozřejmá. Používejte obě technologie společně nejen proto, že můžeme, ale také proto, že se během procesu naučíme něco o XPath, což z něj udělá další nástroj ve vašem zásobníku – takový, o kterém jste možná nevěděli, že tam byl celou dobu! Problém je v tom, že metoda document.evaluate JavaScriptu a různé metody výběru dotazů, které používáme s rozhraními CSS API pro JavaScript, nejsou kompatibilní. Vytvořil jsem kompatibilní API pro dotazování, abychom mohli začít, i když je pravda, že jsem nad tím moc nepřemýšlel, protože je to odchylka od toho, co zde děláme. Zde je poměrně jednoduchý pracovní příklad opakovaně použitelného konstruktoru dotazů: Viz dotaz na peroXPath [forked] od Bryana Rasmussena. Do objektu dokumentu jsem přidal dvě metody: queryCSSSelectors (což je v podstatě querySelectorAll) a queryXPaths. Oba tyto vrátí objekt queryResults:
{ dotaz Typ: uzly | řetězec | číslo | booleovský, výsledky: any[] // html elementy, xml elementy, strings, numbers, booleans, queryCSSSelectors: (dotaz: řetězec, změnit: boolean) => queryResults, queryXpaths: (dotaz: řetězec, změnit: boolean) => queryResults }
Funkce queryCSSSelectors a queryXpaths spustí dotaz, který jim zadáte, nad prvky v poli výsledků, pokud je pole výsledků samozřejmě typu uzly. V opačném případě vrátí queryResult s prázdným polem a typem uzlů. Pokud je vlastnost změnit nastavena na hodnotu true, funkce změní své vlastní queryResults. Za žádných okolností by to nemělo být používáno v produkčním prostředí. Dělám to tímto způsobem čistě proto, abych demonstroval různé účinky společného používání dvou dotazovacích API. Příklady dotazů Chci ukázat několik příkladů různých dotazů XPath, které demonstrují některé z výkonných věcí, které mohou dělat, a jak je lze použít místo jiných přístupů. Prvním příkladem je //li/text(). Tím se zeptá všech prvků li a vrátí jejich textové uzly. Pokud bychom se tedy zeptali na následující HTML:
- jeden
- dva
- tři
...toto se vrací:
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
Jinými slovy, dostaneme následující pole: ["jeden","dva","tři"]. Normálně byste se dotazovali na prvky li, abyste to získali, převedli výsledek tohoto dotazu na pole, namapovali pole a vrátili textový uzel každého prvku. Ale můžeme to udělat stručněji s XPath: document.queryXPaths("//li/text()").výsledky.
Všimněte si, že způsob, jak získat textový uzel, je použít text(), který vypadá jako podpis funkce – a také je. Vrací textový uzel prvku. V našem příkladu jsou v označení tři prvky li, z nichž každý obsahuje text („jeden“, „dva“ a „tři“).
Podívejme se na další příklad dotazu text(). Předpokládejme, že toto je naše označení:
Pojďme napsat dotaz, který vrátí hodnotu atributu href: document.queryXPaths("//a[text() = 'Přihlásit se']/@href").výsledky.
Toto je dotaz XPath na aktuální dokument, stejně jako v posledním příkladu, ale tentokrát vrátíme atribut href odkazu (prvku), který obsahuje text „Přihlásit se“. Skutečné se vrátilovýsledkem je ["/login.html"]. Přehled funkcí XPath Existuje řada funkcí XPath a pravděpodobně je neznáte. Myslím, že existuje několik, o kterých stojí za to vědět, včetně následujících:
začíná-s Pokud text začíná konkrétním jiným textovým příkladem, funkce begin-with(@href, 'http:') vrátí hodnotu true, pokud atribut href začíná http:. obsahuje-li text obsahuje konkrétní příklad jiného textu, obsahuje(text(), "Smashing Magazine") vrátí hodnotu true, pokud textový uzel kdekoli obsahuje slova "Smashing Magazine". countVrátí počet, kolik shod existuje s dotazem. Například count(//*[starts-with(@href, 'http:']) vrátí počet, kolik odkazů v kontextovém uzlu má prvky s atributem href, který obsahuje text začínající http:. substringFunguje jako podřetězec JavaScriptu, ale předáte řetězec jako argument. Například substring("můj text", 2, 4) vrátí "y t". substring-beforeVrátí část řetězce před jiný řetězec. Například substing-before("můj text", " ") vrátí "můj". Podobně substring-before("hi","bye") vrátí prázdný řetězec. substring-afterVrátí část řetězce za jiným řetězcem. Například substing-after("můj text", " ") vrátí "text". Podobně substring-after("hi","bye") vrátí prázdný řetězec. normalize-space Vrátí řetězec argumentů s bílými znaky normalizovanými odstraněním úvodních a koncových bílých znaků a nahrazením sekvence bílých znaků jednou mezerou. notVrátí logickou hodnotu true, pokud je argument nepravdivý, jinak nepravdivý. true Vrací boolean true. false Vrací logickou hodnotu false. concatTo samé jako JavaScript concat, kromě toho, že to nespouštíte jako metodu na řetězci. Místo toho vložíte všechny řetězce, které chcete zřetězit. string-lengthTo není totéž jako JavaScript string-length, ale spíše vrací délku řetězce, který je zadán jako argument. translateThis vezme řetězec a změní druhý argument na třetí argument. Například translate("abcdef", "abc", "XYZ") vypíše XYZdef.
Kromě těchto konkrétních funkcí XPath existuje řada dalších funkcí, které fungují stejně jako jejich protějšky v JavaScriptu – nebo protějšky v podstatě v jakémkoli programovacím jazyce – a které byste pravděpodobně také považovali za užitečné, jako je podlaha, strop, zaokrouhlení, součet a tak dále. Následující ukázka ilustruje každou z těchto funkcí: Viz Numerické funkce pera XPath [rozvětvené] od Bryana Rasmussena. Všimněte si, že stejně jako většina funkcí pro manipulaci s řetězci, mnoho z numerických funkcí přijímá jediný vstup. To je samozřejmě proto, že se mají používat pro dotazování, jako v posledním příkladu XPath: //li[podlaha(text()) > 250]/@val
Pokud je použijete, jako většina příkladů, skončíte tak, že jej spustíte na prvním uzlu, který odpovídá cestě. Existují také některé funkce převodu typů, kterým byste se pravděpodobně měli vyhnout, protože JavaScript již má své vlastní problémy s převodem typů. Ale mohou nastat situace, kdy budete chtít převést řetězec na číslo, abyste jej porovnali s jiným číslem. Funkce, které nastavují typ něčeho, jsou boolean, číslo, řetězec a uzel. Toto jsou důležité datové typy XPath. A jak si dokážete představit, většinu těchto funkcí lze použít na datových typech, které nejsou uzly DOM. Například substring-after přebírá řetězec, jak jsme již popsali, ale může to být řetězec z atributu href. Může to být také jen řetězec:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Je zřejmé, že tento příklad nám vrátí pole výsledků jako ["svět"]. Abych to ukázal v akci, vytvořil jsem ukázkovou stránku pomocí funkcí proti věcem, které nejsou uzly DOM: Viz dotaz na peroXPath [forked] od Bryana Rasmussena. Měli byste si povšimnout překvapivého aspektu funkce překladu, který spočívá v tom, že pokud máte znak ve druhém argumentu (tj. v seznamu znaků, které chcete přeložit) a žádný odpovídající znak k překladu, bude tento znak z výstupu odstraněn. Tedy toto:
translate('Ahoj, jmenuji se Inigo Montoya, zabil jsi mého otce, připrav se zemřít','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…výsledky v řetězci včetně mezer: [" * * ** "]
To znamená, že písmeno „a“ se překládá na hvězdičku (*), ale každý další znak, který nemá překlad daný cílovým řetězcem, je zcela odstraněn. Bílá místa jsou vše, co nám zbylomezi přeloženými znaky „a“. Pak znovu tento dotaz:
translate('Ahoj, jmenuji se Inigo Montoya, zabil jsi mého otce, připrav se zemřít','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************')")
…nemá problém a vydá výsledek, který vypadá takto:
"***** ** **** ** ***** ******* *** ******** ** **** ******** ** ***"
Mohlo by vás napadnout, že v JavaScriptu neexistuje žádný snadný způsob, jak udělat přesně to, co dělá funkce XPath translate, i když v mnoha případech to dokáže nahradit vše pomocí regulárních výrazů. Můžete použít stejný přístup, který jsem předvedl, ale to není optimální, pokud chcete pouze překládat řetězce. Následující ukázka obsahuje funkci překladu XPath a poskytuje verzi JavaScriptu: Viz funkce překladu pera [forked] od Bryana Rasmussena. Kde můžete něco takového použít? Zvažte šifrování Caesar Cipher s třímístným offsetem (např. šifrování nejvyšší úrovně z roku 48 př. n. l.):
translate("Caesar plánuje překročit Rubikon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Vstupní text „Caesar plánuje překročit Rubikon!“ výsledkem je „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!“ Abych uvedl další rychlý příklad různých možností, vytvořil jsem kovovou funkci, která přebírá vstup řetězce a pomocí funkce překladu vrací text, včetně všech znaků, které berou přehlásky. Podívejte se na funkci Pen metal [forked] od Bryana Rasmussena.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
A pokud dostanete text „Pravidla Motley Crue, rock on Dudes!“, vrátí „Mötley Crüe rüles, röck ön düdes!“ Je zřejmé, že tuto funkci lze parodovat různými způsoby. Pokud jste to vy, pak by vám tento článek TVTropes měl poskytnout spoustu inspirace. Použití CSS s XPath Pamatujte si náš hlavní důvod pro použití selektorů CSS společně s XPath: CSS do značné míry rozumí tomu, co je třída, zatímco nejlepší, co můžete s XPath udělat, je porovnávání řetězců atributu class. To bude fungovat ve většině případů. Ale pokud byste se někdy dostali do situace, kdy, řekněme, někdo vytvořil třídy s názvem .primaryLinks a .primaryLinks2 a vy jste používali XPath k získání třídy .primaryLinks, pak byste pravděpodobně narazili na problémy. Dokud není nic takového hloupého, pravděpodobně byste použili XPath. S lítostí však musím oznámit, že jsem pracoval na místech, kde lidé dělají takové hlouposti. Zde je další ukázka využívající CSS a XPath společně. Ukazuje, co se stane, když použijeme kód ke spuštění XPath v kontextovém uzlu, který není uzlem dokumentu. Podívejte se na Pen css a xpath společně [forked] od Bryana Rasmussena. Dotaz CSS je .relatedarticles a, který načte dva prvky a v prvku div, kterému je přiřazena třída .relatedarticles. Poté následují tři „špatné“ dotazy, to znamená dotazy, které nedělají to, co po nich chceme, když běží s těmito prvky jako kontextovým uzlem. Dokážu vysvětlit, proč se chovají jinak, než byste čekali. Tyto tři špatné dotazy jsou:
//text(): Vrátí veškerý text v dokumentu. //a/text(): Vrátí veškerý text uvnitř odkazů v dokumentu. ./a/text(): Nevrací žádné výsledky.
Důvodem těchto výsledků je, že zatímco váš kontext je prvky vrácené z dotazu CSS, // jde proti celému dokumentu. To je síla XPath; CSS nemůže přejít z uzlu nahoru k předkovi a poté k sourozenci tohoto předka a přejít dolů k potomkovi tohoto sourozence. Ale XPath umí. Mezitím se ./ dotáže na potomky aktuálního uzlu, kde tečka (.) představuje aktuální uzel a lomítko (/) představuje přechod na nějaký podřízený uzel – zda se jedná o atribut, prvek nebo text, je určeno další částí cesty. Ale neexistuje žádný podřízený prvek vybraný dotazem CSS, takže tento dotaz také nic nevrací. V tom posledním demu jsou tři dobré dotazy:
.//text(), ./text(), normalize-space(./text()).
Dotaz normalizace prostoru demonstruje použití funkce XPath, ale také řeší problém obsažený v ostatních dotazech. HTML je strukturováno takto:
Automatizace testování funkcí pomocí Selenium WebDriver
Dotaz vrací odřádkování na začátku a na konci textového uzlu,a normalize-space to odstraní. Použití jakékoli funkce XPath, která vrací něco jiného než logickou hodnotu se vstupem XPath, platí pro ostatní funkce. Následující ukázka ukazuje několik příkladů: Viz příklady funkcí Pen xpath [forked] od Bryana Rasmussena. První příklad ukazuje problém, na který byste si měli dát pozor. Konkrétně následující kód:
document.queryXPaths("substring-after(//a/@href,'https://')");
...vrací jeden řetězec:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Dává to smysl, ne? Tyto funkce nevracejí pole, ale spíše jednotlivé řetězce nebo jednotlivá čísla. Spuštění funkce kdekoli s více výsledky vrátí pouze první výsledek. Druhý výsledek ukazuje, co opravdu chceme:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Což vrací pole dvou řetězců:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Funkce XPath mohou být vnořeny stejně jako funkce v JavaScriptu. Pokud tedy známe strukturu URL Smashing Magazine, mohli bychom udělat následující (doporučujeme použít šablonové literály): `přeložit( podřetězec ( substring-after(./@href, ‚www.smashingmagazine.com/') ,9), '/','')".
Začíná to být příliš složité do té míry, že to vyžaduje komentáře popisující, co to dělá: vezměte všechny adresy URL z atributu href za www.smashingmagazine.com/, odstraňte prvních devět znaků a poté přeložte znak lomítka (/) na nic, abyste se zbavili koncového lomítka. Výsledné pole:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Více případů použití XPath XPath může v testování opravdu zazářit. Důvod není těžké pochopit, protože XPath lze použít k získání každého prvku v DOM z libovolné pozice v DOM, zatímco CSS nikoli. Nemůžete počítat s tím, že třídy CSS zůstanou konzistentní v mnoha moderních sestavovacích systémech, ale s XPath jsme schopni vytvořit robustnější shodu, pokud jde o to, jaký je textový obsah prvku, bez ohledu na měnící se strukturu DOM. Byl proveden výzkum technik, které vám umožňují provádět odolné testy XPath. Není nic horšího, než když testy vypadnou a selžou jen proto, že selektor CSS již nefunguje, protože bylo něco přejmenováno nebo odstraněno. XPath je také opravdu skvělý při extrakci více lokátorů. Existuje více než jeden způsob, jak pomocí dotazů XPath najít shodu s prvkem. To samé platí s CSS. Dotazy XPath však mohou proniknout do věcí cílenějším způsobem, který omezí to, co se vrátí, což vám umožní najít konkrétní shodu, kde může být několik možných shod. Například můžeme použít XPath k vrácení konkrétního prvku h2, který je obsažen v prvku div, který bezprostředně následuje po sourozeneckém prvku div, který zase obsahuje podřízený prvek obrázku s atributem data-testID="leader":
Nechápu tento nadpis
Nechápejte ani tento nadpis
Záhlaví obrázku odkazu
Toto je dotaz: document.queryXPaths(` //div[ následující-sourozenec::div[1] /img[@data-testID='leader'] ] /h2/ text() `);
Podívejme se na ukázku, abychom viděli, jak to všechno jde dohromady: Viz dotaz na Pen Complex H2 [rozvětvený] od Bryana Rasmussena. Takže ano. Existuje mnoho možných cest k jakémukoli prvku v testu pomocí XPath. Podpora XSLT 1.0 Již dříve jsem zmínil, že tým Chrome plánuje z prohlížeče odstranit podporu XSLT 1.0. To je důležité, protože XSLT 1.0 používá pro transformaci dokumentů programování zaměřené na XML, které zase spoléhá na XPath 1.0, což je to, co se nachází ve většině prohlížečů. Když k tomu dojde, ztratíme klíčovou součást XPath. Ale vzhledem k tomu, že XPath je opravdu skvělý pro psaní testů, považuji za nepravděpodobné, že by XPath jako celek v dohledné době zmizel. To znamená, že jsem si všiml, že lidé mají zájem o funkci, když je odebrána. A to jistě platí v případě zastaralého XSLT 1.0. V Hacker News probíhá celá diskuse plná argumentů proti zrušení podpory. Samotný příspěvek je skvělým příkladem vytvoření rámce pro blogování pomocí XSLT. Vysi můžete přečíst diskusi sami, ale dostává se k tomu, jak by mohl být JavaScript použit jako podložka pro XLST pro řešení takových případů. Také jsem viděl návrhy, že prohlížeče by měly používat SaxonJS, což je port pro JavaScriptové motory Saxon XSLT, XQUERY a XPath. To je zajímavý nápad, zvláště když Saxon-JS implementuje aktuální verzi těchto specifikací, zatímco neexistuje žádný prohlížeč, který by implementoval jakoukoli verzi XPath nebo XSLT vyšší než 1.0, a žádný, který by implementoval XQuery. Oslovil jsem Norm Tovey-Walsh ze Saxonica, společnost stojící za SaxonJS a dalšími verzemi saského motoru. Řekl: „Pokud by některý z výrobců prohlížečů měl zájem vzít SaxonJS jako výchozí bod pro integraci moderních technologií XML do prohlížeče, rádi bychom to s ním probrali.“ – Norm Tovey-Walsh
Ale také dodal: "Byl bych velmi překvapen, kdyby si někdo myslel, že převzít SaxonJS v jeho současné podobě a vložit jej do sestavení prohlížeče beze změny by byl ideální přístup. Prodejce prohlížeče, vzhledem k tomu, že staví prohlížeč, by mohl přistoupit k integraci na mnohem hlubší úrovni, než můžeme "zvenčí"." - Norm Tovey-Walsh
Stojí za zmínku, že komentáře Tovey-Walshe přišly asi týden před oznámením o ukončení podpory XSLT. Závěr Mohl bych pokračovat dál a dál. Ale doufám, že to prokázalo sílu XPath a poskytlo vám spoustu příkladů, jak jej použít k dosažení velkých věcí. Je to dokonalý příklad starší technologie v zásobníku prohlížečů, která má i dnes spoustu užitečných funkcí, i když jste nikdy nevěděli, že existuje, nebo jste nikdy neuvažovali o tom, že po ní sáhnete. Další čtení
„Zlepšení odolnosti automatických webových testů pomocí přirozeného jazyka“ (Digitální knihovna ACM) od Marouna Ayliho, Youssefa Bakounyho, Nadera Jalloula a Rimy Kilanyové Tento článek poskytuje mnoho příkladů XPath pro psaní testů odolnosti. XPath (MDN) Toto je skvělé místo, kde začít, pokud chcete technické vysvětlení podrobně popisující, jak XPath funguje. XPath Tutorial (ZVON) Zjistil jsem, že tento tutoriál je pro mé vlastní učení nejužitečnější, a to díky množství příkladů a jasných vysvětlení. XPatherTento interaktivní nástroj vám umožňuje pracovat přímo s kódem.