Zajmuję się tworzeniem front-endu wystarczająco długo, aby dostrzec trend na przestrzeni lat: młodsi programiści pracują z nowym paradygmatem programowania, nie rozumiejąc jego historycznego kontekstu. Niewiedzenie czegoś jest oczywiście całkowicie zrozumiałe. Sieć to bardzo duże miejsce z różnorodnym zestawem umiejętności i specjalizacji i nie zawsze wiemy, czego nie wiemy. Nauka w tej dziedzinie to ciągła podróż, a nie coś, co dzieje się raz i kończy. Przykład: ktoś z mojego zespołu zapytał, czy można stwierdzić, czy użytkownicy opuszczają określoną kartę w interfejsie użytkownika. Wspomniałem o zdarzeniu beforeunload JavaScriptu. Jednak ci, którzy zajmowali się tym wcześniej, wiedzą, że jest to możliwe, ponieważ otrzymywali powiadomienia o niezapisanych danych w innych witrynach, dla których typowym przypadkiem użycia jest beforeunload. Na dokładkę wskazałem też stronęUkryj i widocznośćZmień wydarzenia mojemu koledze. Skąd o tym wiedziałem? Ponieważ pojawił się w innym projekcie, a nie dlatego, że uczyłem się go na początku nauki JavaScript. Faktem jest, że nowoczesne frameworki front-endowe stoją na barkach technologicznych gigantów, którzy je poprzedzili. Abstrakcjonują praktyki programistyczne, często w celu lepszego doświadczenia programisty, co zmniejsza, a nawet eliminuje potrzebę poznania lub dotknięcia tego, co tradycyjnie było niezbędnymi koncepcjami front-endu, które prawdopodobnie każdy powinien znać. Rozważmy model obiektowy CSS (CSSOM). Można się spodziewać, że każdy, kto pracuje w CSS i JavaScript, ma mnóstwo praktycznego doświadczenia w CSSOM, ale nie zawsze tak będzie. Pracowałem nad projektem React dla witryny e-commerce, w którym musieliśmy załadować arkusz stylów dla aktualnie wybranego dostawcy płatności. Problem polegał na tym, że arkusz stylów ładował się na każdej stronie, podczas gdy był naprawdę potrzebny tylko na określonej stronie. Programista, któremu powierzono to zadanie, nigdy nie ładował dynamicznie arkusza stylów. Ponownie jest to całkowicie zrozumiałe, gdy React odchodzi od tradycyjnego podejścia, po które mogłeś sięgnąć. CSSOM prawdopodobnie nie jest czymś, czego potrzebujesz w codziennej pracy. Jednak prawdopodobnie w pewnym momencie będziesz musiał z nim wejść w interakcję, nawet w jednorazowym przypadku. Te doświadczenia zainspirowały mnie do napisania tego artykułu. Istnieje wiele istniejących funkcji i technologii internetowych, których być może nigdy nie dotkniesz bezpośrednio w swojej codziennej pracy. Być może dopiero zaczynasz przygodę z tworzeniem stron internetowych i po prostu nie jesteś ich świadomy, ponieważ jesteś pogrążony w abstrakcji określonego frameworka, który nie wymaga od ciebie głębokiej wiedzy ani nawet żadnej. Mówię konkretnie o XML, który wielu z nas wie, że jest starożytnym językiem, niewiele różniącym się od HTML. Poruszam tę kwestię ze względu na niedawne dyskusje WHATWG sugerujące, że znaczna część stosu XML, znana jako programowanie XSLT, powinna zostać usunięta z przeglądarek. Jest to dokładnie ten rodzaj starszej, istniejącej technologii, którą mamy od lat, a którą można wykorzystać w czymś tak praktycznym, jak sytuacja CSSOM, w której znajdował się mój zespół. Czy pracowałeś już z XSLT? Zobaczmy, czy mocno oprzemy się na tej starszej technologii i wykorzystamy jej funkcje poza kontekstem XML, aby stawić czoła współczesnym problemom. XPath: Centralne API Najważniejszą technologią XML, która jest być może najbardziej użyteczna poza prostą perspektywą XML, jest XPath, język zapytań, który pozwala znaleźć dowolny węzeł lub atrybut w drzewie znaczników z jednym elementem głównym. Mam osobisty sentyment do XSLT, ale to również opiera się na XPath, a osobiste uczucia należy odłożyć na bok w rankingu ważności. Argument za usunięciem XSLT nie wspomina o XPath, więc przypuszczam, że jest on nadal dozwolony. To dobrze, ponieważ XPath jest centralnym i najważniejszym interfejsem API w tym zestawie technologii, zwłaszcza gdy próbujesz znaleźć coś, co można wykorzystać poza normalnym użyciem XML. Jest to ważne, ponieważ chociaż selektorów CSS można użyć do znalezienia większości elementów na stronie, nie są one w stanie znaleźć ich wszystkich. Co więcej, selektorów CSS nie można używać do znajdowania elementu na podstawie jego bieżącej pozycji w DOM. XPath może. Niektórzy z Was, którzy to czytają, mogą znać XPath, a niektórzy nie. XPath to dość duży obszar technologii i tak naprawdę nie mogę nauczyć wszystkich podstaw, a także pokazać Ci fajne rzeczy, które można z nim zrobić w jednym artykule takim jak ten. Właściwie próbowałem napisać ten artykuł, ale przeciętna publikacja w Smashing Magazine nie przekracza 5000 słów. Byłem już na ponad2000 słów, będąc dopiero w połowie podstaw. Zamierzam więc zacząć robić fajne rzeczy z XPath i dać ci kilka linków, z których możesz skorzystać, aby poznać podstawy, jeśli uznasz to za interesujące. Łączenie XPath i CSS XPath może robić wiele rzeczy, których nie potrafią selektory CSS podczas wysyłania zapytań do elementów. Jednak selektory CSS mogą również robić kilka rzeczy, których nie potrafi XPath, a mianowicie sprawdzać elementy według nazwy klasy.
CSS XPath .mojaKlasa /*[zawiera(@klasa, "mojaKlasa")]
W tym przykładzie CSS wysyła zapytanie do elementów zawierających nazwę klasy .myClass. Tymczasem przykład XPath wysyła zapytanie do elementów zawierających klasę atrybutów za pomocą ciągu „myClass”. Innymi słowy, wybiera elementy z myClass w dowolnym atrybucie, w tym elementy z nazwą klasy .myClass — a także elementy z ciągiem „myClass”, takie jak .myClass2. XPath jest w tym sensie szerszy. Więc nie. Nie sugeruję, że powinniśmy porzucić CSS i zacząć wybierać wszystkie elementy za pomocą XPath. Nie o to chodzi. Rzecz w tym, że XPath może robić rzeczy, których CSS nie potrafi, a mimo to może być bardzo przydatny, mimo że jest to starsza technologia w stosie przeglądarki i może nie wydawać się oczywista na pierwszy rzut oka. Wykorzystajmy te dwie technologie razem nie tylko dlatego, że możemy, ale także dlatego, że przy okazji dowiemy się czegoś o XPath, dzięki czemu stanie się ono kolejnym narzędziem w Twoim stosie — takim, o którym być może nie miałeś pojęcia, że istnieje od zawsze! Problem polega na tym, że metoda document.evaluate JavaScriptu i różne metody selektora zapytań, których używamy z interfejsami API CSS dla JavaScript, są niekompatybilne. Na początek stworzyłem kompatybilny interfejs API do wysyłania zapytań, chociaż przyznaję, że nie poświęciłem temu zbyt wiele uwagi, ponieważ stanowi to odejście od tego, co tutaj robimy. Oto dość prosty działający przykład konstruktora zapytań wielokrotnego użytku: Zobacz zapytanie Pen queryXPath [rozwidlone] autorstwa Bryana Rasmussena. Dodałem dwie metody do obiektu dokumentu: queryCSSSelectors (który w zasadzie jest querySelectorAll) i queryXPaths. Obydwa zwracają obiekt queryResults:
{ typ zapytania: węzły | ciąg | numer | wartość logiczna, wyniki: any[] // elementy HTML, elementy XML, ciągi znaków, liczby, wartości logiczne, queryCSSSelectors: (zapytanie: string, poprawka: boolean) => queryResults, queryXpaths: (zapytanie: string, poprawka: boolean) => queryResults }
Funkcje queryCSSSelectors i queryXpaths uruchamiają podane przez Ciebie zapytanie dotyczące elementów tablicy wyników, o ile oczywiście tablica wyników jest typu węzłów. W przeciwnym razie zwróci zapytanieResult z pustą tablicą i typem węzłów. Jeśli właściwość amend jest ustawiona na true, funkcje zmienią własne wyniki zapytania. W żadnym wypadku nie należy tego używać w środowisku produkcyjnym. Robię to w ten sposób wyłącznie po to, aby zademonstrować różne efekty jednoczesnego używania dwóch interfejsów API zapytań. Przykładowe zapytania Chcę pokazać kilka przykładów różnych zapytań XPath, które pokazują niektóre z potężnych rzeczy, które mogą zrobić i jak można je wykorzystać zamiast innych podejść. Pierwszym przykładem jest //li/text(). To wysyła zapytanie do wszystkich elementów li i zwraca ich węzły tekstowe. Jeśli więc zapytamy o następujący kod HTML:
- jeden
- dwa
- trzy
…to jest zwracane:
{"queryType":"xpathEvaluate","results":["jeden","dwa","trzy"],"resultType":"string"}
Inaczej mówiąc, otrzymujemy następującą tablicę: ["jeden", "dwa", "trzy"]. Zwykle w tym celu należy zapytać o elementy li, przekształcić wynik tego zapytania w tablicę, zmapować tablicę i zwrócić węzeł tekstowy każdego elementu. Ale możemy to zrobić bardziej zwięźle za pomocą XPath: document.queryXPaths("//li/text()").results.
Zauważ, że sposobem na uzyskanie węzła tekstowego jest użycie funkcji tekstowej (), która wygląda jak sygnatura funkcji — i rzeczywiście tak jest. Zwraca węzeł tekstowy elementu. W naszym przykładzie znacznik zawiera trzy elementy li, z których każdy zawiera tekst („jeden”, „dwa” i „trzy”).
Przyjrzyjmy się jeszcze jednemu przykładowi zapytania tekstowego(). Załóżmy, że to jest nasz znacznik:
Napiszmy zapytanie, które zwróci wartość atrybutu href: document.queryXPaths("//a[text() = 'Zaloguj się']/@href").results.
Jest to zapytanie XPath dotyczące bieżącego dokumentu, podobnie jak w ostatnim przykładzie, ale tym razem zwracamy atrybut href łącza (elementu), który zawiera tekst „Zaloguj się”. Rzeczywista wróciławynik to ["/login.html"]. Przegląd funkcji XPath Istnieje wiele funkcji XPath i prawdopodobnie ich nie znasz. Myślę, że jest kilka, o których warto wiedzieć, m.in.:
zaczyna się odJeśli tekst zaczyna się od określonego innego przykładu tekstu, funkcja zaczyna się od(@href, 'http:') zwraca wartość true, jeśli atrybut href zaczyna się od http:. zawieraJeśli tekst zawiera konkretny inny przykład tekstu, funkcja zawiera(text(), „Smashing Magazine”) zwraca wartość true, jeśli węzeł tekstowy zawiera w dowolnym miejscu słowa „Smashing Magazine”. countZwraca liczbę dopasowań do zapytania. Na przykład funkcja count(//*[starts-with(@href, 'http:']) zwraca liczbę linków w węźle kontekstu zawierających elementy z atrybutem href zawierającym tekst rozpoczynający się od http:. substringDziała jak podciąg JavaScript, z tą różnicą, że przekazujesz ciąg jako argument. Na przykład substring("mój tekst", 2, 4) zwraca "y t". substring-before Zwraca część łańcucha poprzedzającą inny ciąg. Na przykład substing-before("mój tekst", " ") zwraca "mój". Podobnie substring-before("cześć","bye") zwraca pusty ciąg. substring-afterZwraca część łańcucha po innym ciągu. Na przykład substing-after("mój tekst", " ") zwraca "tekst". Podobnie substring-after("cześć","bye") zwraca pusty ciąg. normalize-space Zwraca ciąg argumentów ze spacjami znormalizowanymi poprzez usunięcie początkowych i końcowych białych znaków oraz zastąpienie sekwencji białych znaków pojedynczą spacją. notZwraca wartość logiczną true, jeśli argument jest fałszywy, w przeciwnym razie false. true Zwraca wartość logiczną true. falseZwraca wartość logiczną false. concatTo samo, co concat JavaScript, z tą różnicą, że nie uruchamiasz go jako metody na ciągu znaków. Zamiast tego umieszczasz wszystkie ciągi, które chcesz połączyć. długość-ciągu Nie jest to to samo, co długość łańcucha w JavaScript, ale raczej zwraca długość łańcucha podanego jako argument. tłumaczPobiera ciąg znaków i zmienia drugi argument na trzeci. Na przykład tłumaczenie("abcdef", "abc", "XYZ") zwraca XYZdef.
Oprócz tych konkretnych funkcji XPath istnieje wiele innych funkcji, które działają tak samo, jak ich odpowiedniki w JavaScript — lub odpowiedniki w zasadzie w dowolnym języku programowania — które prawdopodobnie również okazałyby się przydatne, takie jak podłoga, sufit, okrągła, suma i tak dalej. Poniższe demo ilustruje każdą z tych funkcji: Zobacz funkcje numeryczne Pen XPath [rozwidlone] autorstwa Bryana Rasmussena. Należy zauważyć, że podobnie jak większość funkcji manipulacji ciągami znaków, wiele funkcji numerycznych wymaga pojedynczego wejścia. Dzieje się tak oczywiście dlatego, że mają one służyć do wykonywania zapytań, jak w ostatnim przykładzie XPath: //li[podłoga(tekst()) > 250]/@val
Jeśli ich użyjesz, jak ma to miejsce w większości przykładów, uruchomisz je w pierwszym węźle pasującym do ścieżki. Istnieją również pewne funkcje konwersji typów, których prawdopodobnie powinieneś unikać, ponieważ JavaScript ma już własne problemy z konwersją typów. Może się jednak zdarzyć, że zechcesz przekonwertować ciąg na liczbę, aby porównać go z inną liczbą. Funkcje ustawiające typ czegoś to wartość logiczna, liczba, ciąg znaków i węzeł. Są to ważne typy danych XPath. Jak można sobie wyobrazić, większości tych funkcji można używać w przypadku typów danych, które nie są węzłami DOM. Na przykład substring-after pobiera ciąg znaków, jak już omówiliśmy, ale może to być ciąg z atrybutu href. Może to być również po prostu ciąg znaków:
const testSubstringAfter = document.queryXPaths("substring-after('witaj świecie',' ')");
Oczywiście ten przykład zwróci nam tablicę wyników jako ["świat"]. Aby pokazać to w akcji, stworzyłem stronę demonstracyjną, używając funkcji przeciwko elementom, które nie są węzłami DOM: Zobacz zapytanie Pen queryXPath [rozwidlone] autorstwa Bryana Rasmussena. Powinieneś zwrócić uwagę na zaskakujący aspekt funkcji tłumaczenia, który polega na tym, że jeśli w drugim argumencie znajduje się znak (tj. lista znaków, które chcesz przetłumaczyć) i nie ma pasującego znaku do przetłumaczenia, znak ten zostanie usunięty z wyniku. Zatem to:
tłumacz('Witam, nazywam się Inigo Montoya, zabiłeś mojego ojca, przygotuj się na śmierć','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…wynikiem jest ciąg znaków łącznie ze spacjami: [" * * ** "]
Oznacza to, że litera „a” jest tłumaczona na gwiazdkę (*), ale każdy inny znak, który nie ma tłumaczenia, biorąc pod uwagę docelowy ciąg znaków, jest całkowicie usuwany. Biała spacja to wszystko, co nam pozostałopomiędzy przetłumaczonymi znakami „a”. Potem jeszcze raz to zapytanie:
tłumacz('Witam, nazywam się Inigo Montoya, zabiłeś mojego ojca, przygotuj się na śmierć','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")
…nie ma tego problemu i zwraca wynik wyglądający tak:
„***** ** **** ** ***** ********** *** ****** ** ****** ********** ** ***”
Może cię uderzyć, że w JavaScript nie ma łatwego sposobu na wykonanie dokładnie tego, co robi funkcja tłumaczenia XPath, chociaż w wielu przypadkach radzi sobie z tym funkcja zamień wszystko na wyrażenia regularne. Możesz zastosować to samo podejście, które pokazałem, ale jest to nieoptymalne, jeśli chcesz jedynie przetłumaczyć ciągi znaków. Poniższe demo podsumowuje funkcję tłumaczenia XPath, aby udostępnić wersję JavaScript: Zobacz funkcję tłumaczenia pióra [rozwidloną] autorstwa Bryana Rasmussena. Gdzie można zastosować coś takiego? Rozważmy szyfrowanie Cezara z trzymiejscowym przesunięciem (np. szyfrowanie najwyższej klasy z 48 r. p.n.e.):
tłumacz("Cezar planuje przekroczyć Rubikon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Tekst wejściowy „Cezar planuje przekroczyć Rubikon!” skutkuje „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Aby dać kolejny szybki przykład różnych możliwości, stworzyłem metalową funkcję, która pobiera ciąg znaków i używa funkcji tłumaczenia w celu zwrócenia tekstu, łącznie ze wszystkimi znakami przyjmującymi umlauty. Zobacz metalową funkcję Pen [rozwidloną] autorstwa Bryana Rasmussena.
const metal = (str) => { return tłumacz(str, "AOUaou","ĘÖÜäöü"); }
A jeśli otrzymamy tekst „Motley Crue rządzi, dajcie spokój, kolesie!”, zwraca „Mötley Crüe rüles, röck ön düdes!” Oczywiście można mieć wiele parodyjnych zastosowań tej funkcji. Jeśli to ty, to ten artykuł TVTropes powinien dostarczyć ci mnóstwo inspiracji. Używanie CSS z XPath Pamiętaj o naszym głównym powodzie używania selektorów CSS razem z XPath: CSS prawie rozumie, czym jest klasa, podczas gdy najlepsze, co można zrobić z XPath, to porównania ciągów atrybutu klasy. To zadziała w większości przypadków. Jeśli jednak kiedykolwiek spotkasz się z sytuacją, w której ktoś, powiedzmy, utworzył klasy o nazwach .primaryLinks i .primaryLinks2, a Ty używasz XPath do uzyskania klasy .primaryLinks, prawdopodobnie napotkasz problemy. O ile nie ma nic takiego głupiego, prawdopodobnie użyłbyś XPath. Ale ze smutkiem muszę poinformować, że pracowałem w miejscach, gdzie ludzie robią tego typu głupie rzeczy. Oto kolejna demonstracja wykorzystująca jednocześnie CSS i XPath. Pokazuje, co się stanie, gdy użyjemy kodu do uruchomienia XPath w węźle kontekstu, który nie jest węzłem dokumentu. Zobacz wspólne css i xpath pióra [rozwidlone] autorstwa Bryana Rasmussena. Zapytanie CSS to .latedarticles a, które pobiera dwa elementy a z elementu div z przypisaną klasą .boundarticles. Następnie są trzy „złe” zapytania, to znaczy zapytania, które nie robią tego, czego od nich oczekujemy, gdy działają z tymi elementami jako węzłem kontekstu. Potrafię wyjaśnić, dlaczego zachowują się inaczej, niż można by się spodziewać. Trzy złe zapytania, o których mowa, to:
//text(): Zwraca cały tekst w dokumencie. //a/text(): Zwraca cały tekst znajdujący się wewnątrz łączy w dokumencie. ./a/text(): Nie zwraca żadnych wyników.
Powodem tych wyników jest to, że chociaż kontekst jest elementem zwróconym przez zapytanie CSS, // jest sprzeczny z całym dokumentem. To jest siła XPath; CSS nie może przejść od węzła do przodka, a następnie do rodzeństwa tego przodka i zejść do potomka tego rodzeństwa. Ale XPath może. Tymczasem ./ wysyła zapytanie do dzieci bieżącego węzła, gdzie kropka (.) reprezentuje bieżący węzeł, a ukośnik (/) oznacza przejście do jakiegoś węzła podrzędnego — czy jest to atrybut, element czy tekst, zależy od następnej części ścieżki. Ale nie ma elementu potomnego wybranego przez zapytanie CSS, zatem to zapytanie również nic nie zwraca. W tym ostatnim demo są trzy dobre zapytania:
.//tekst(), ./tekst(), normalize-space(./text()).
Zapytanie normalize-space demonstruje użycie funkcji XPath, ale także rozwiązuje problem występujący w innych zapytaniach. Struktura kodu HTML jest następująca:
Automatyzacja testowania funkcji za pomocą Selenium WebDriver
Zapytanie zwraca znak nowej linii na początku i na końcu węzła tekstowego,i normalize-space usuwa to. Użycie dowolnej funkcji XPath, która zwraca wartość inną niż wartość logiczna z wejściową wartością XPath, ma zastosowanie do innych funkcji. Poniższe demo pokazuje kilka przykładów: Zobacz przykłady funkcji Pen xpath [rozwidlone] autorstwa Bryana Rasmussena. Pierwszy przykład pokazuje problem, na który należy zwrócić uwagę. Konkretnie następujący kod:
document.queryXPaths("substring-after(//a/@href,'https://')");
…zwraca jeden ciąg:
„www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/”
To ma sens, prawda? Funkcje te nie zwracają tablic, ale raczej pojedyncze ciągi lub pojedyncze liczby. Uruchomienie funkcji w dowolnym miejscu z wieloma wynikami zwraca tylko pierwszy wynik. Drugi wynik pokazuje, czego naprawdę chcemy:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Który zwraca tablicę dwóch ciągów:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Funkcje XPath można zagnieżdżać podobnie jak funkcje w JavaScript. Jeśli więc znamy strukturę adresu URL Smashing Magazine, moglibyśmy wykonać następujące czynności (zalecane jest użycie literałów szablonu): `przetłumacz( podciąg ( substring-after(./@href, „www.smashingmagazine.com/”) ,9), '/','')`
Robi się to trochę zbyt skomplikowane do tego stopnia, że wymaga komentarza opisującego, co robi: weź cały adres URL z atrybutu href po www.smashingmagazine.com/, usuń pierwszych dziewięć znaków, a następnie przetłumacz znak ukośnika (/) na nic, aby pozbyć się końcowego ukośnika. Wynikowa tablica:
["testowanie funkcji-Selenium-webdriver","wyniki-automatycznych testów-poprawa-dostępności"]
Więcej przypadków użycia XPath XPath może naprawdę zabłysnąć w testach. Powód nie jest trudny do zauważenia, ponieważ XPath może zostać użyty do pobrania każdego elementu DOM z dowolnej pozycji w DOM, podczas gdy CSS nie. Nie można liczyć na to, że klasy CSS pozostaną spójne w wielu nowoczesnych systemach kompilacji, ale dzięki XPath jesteśmy w stanie dokładniej dopasować zawartość tekstową elementu, niezależnie od zmieniającej się struktury DOM. Prowadzono badania nad technikami umożliwiającymi wykonywanie odpornych testów XPath. Nie ma nic gorszego niż błędy i niepowodzenie testów tylko dlatego, że selektor CSS już nie działa, ponieważ zmieniono nazwę czegoś lub coś usunięto. XPath jest również naprawdę świetny w ekstrakcji wielu lokalizatorów. Istnieje więcej niż jeden sposób użycia zapytań XPath w celu dopasowania elementu. To samo dotyczy CSS. Jednak zapytania XPath mogą drążyć rzeczy w bardziej ukierunkowany sposób, ograniczając liczbę zwracanych wyników, umożliwiając znalezienie konkretnego dopasowania, w którym może być kilka możliwych dopasowań. Na przykład możemy użyć XPath do zwrócenia określonego elementu h2 zawartego w elemencie div, który następuje bezpośrednio po div rodzeństwa, który z kolei zawiera element potomny obrazu z atrybutem data-testID="leader":
nie rozumiem tego nagłówka
Tego nagłówka też nie dostaniesz
Nagłówek obrazu lidera
Oto zapytanie: dokument.queryXPaths(` //div[ następujące rodzeństwo::div[1] /img[@data-testID='lider'] ] /h2/ tekst() `);
Wrzućmy wersję demonstracyjną, aby zobaczyć, jak to wszystko się składa: Zobacz zapytanie Pen Complex H2 [rozwidlone] autorstwa Bryana Rasmussena. Więc tak. Istnieje wiele możliwych ścieżek do dowolnego elementu w teście przy użyciu XPath. Wycofanie XSLT 1.0 Wspomniałem wcześniej, że zespół Chrome planuje usunąć z przeglądarki obsługę XSLT 1.0. Jest to ważne, ponieważ XSLT 1.0 wykorzystuje programowanie skupione na XML do transformacji dokumentów, które z kolei opiera się na XPath 1.0, czyli tym, co można znaleźć w większości przeglądarek. Kiedy tak się stanie, stracimy kluczowy komponent XPath. Biorąc jednak pod uwagę fakt, że XPath jest naprawdę świetny do pisania testów, uważam za mało prawdopodobne, aby XPath jako całość wkrótce zniknął. To powiedziawszy, zauważyłem, że ludzie interesują się funkcją, gdy jest ona odbierana. I z pewnością jest to prawdą w przypadku przestarzałego XSLT 1.0. W Hacker News toczy się cała dyskusja wypełniona argumentami przeciwko wycofaniu. Sam post jest doskonałym przykładem tworzenia frameworka blogowego za pomocą XSLT. Tymożesz sam przeczytać dyskusję, ale dotyczy ona tego, w jaki sposób JavaScript może zostać użyty jako podkładka dla XLST do obsługi tego rodzaju przypadków. Widziałem także sugestie, że przeglądarki powinny używać SaxonJS, który jest portem dla silników JavaScript Saxon XSLT, XQUERY i XPath. To ciekawy pomysł, zwłaszcza że Saxon-JS implementuje aktualną wersję tych specyfikacji, podczas gdy nie ma przeglądarki implementującej jakąkolwiek wersję XPath lub XSLT poza 1.0 ani żadnej, która implementuje XQuery. Skontaktowałem się z Normem Tovey-Walshem z Saxonica, firmy stojącej za SaxonJS i innymi wersjami silnika Saxon. Powiedział: „Gdyby jakikolwiek dostawca przeglądarek był zainteresowany przyjęciem SaxonJS jako punktu wyjścia do integracji nowoczesnych technologii XML z przeglądarką, z przyjemnością o tym z nim porozmawiamy.” — Norm Tovey-Walsh
Ale dodał także: "Byłbym bardzo zaskoczony, gdyby ktoś pomyślał, że idealnym podejściem byłoby zabranie SaxonJS w jego obecnej formie i upuszczenie go w niezmienionej formie do kompilacji przeglądarki. Dostawca przeglądarki, ze względu na fakt, że buduje przeglądarkę, może podejść do integracji na znacznie głębszym poziomie, niż możemy to zrobić „z zewnątrz”.” — Norm Tovey-Walsh
Warto zauważyć, że komentarze Tovey-Walsha pojawiły się około tydzień przed ogłoszeniem wycofania XSLT. Wniosek Mógłbym tak dalej. Mam jednak nadzieję, że pokazało to siłę XPath i dało mnóstwo przykładów pokazujących, jak go używać do osiągania wielkich rzeczy. Jest to doskonały przykład starszej technologii w stosie przeglądarek, która nadal ma wiele użyteczności, nawet jeśli nigdy nie wiedziałeś o jej istnieniu lub nigdy nie rozważałeś po nią sięgnąć. Dalsze czytanie
„Zwiększanie odporności zautomatyzowanych testów internetowych za pomocą języka naturalnego” (Biblioteka cyfrowa ACM) autorstwa Marouna Ayli, Youssefa Bakouny, Nadera Jalloula i Rimy Kilany. W tym artykule przedstawiono wiele przykładów XPath dotyczących pisania testów odpornych. XPath (MDN) To doskonałe miejsce na rozpoczęcie, jeśli potrzebujesz technicznego wyjaśnienia szczegółowo opisującego działanie XPath. Samouczek XPath (ZVON) Uważam, że ten samouczek jest najbardziej pomocny w mojej nauce, dzięki mnóstwu przykładów i jasnym objaśnieniom. XPatherTo interaktywne narzędzie umożliwia bezpośrednią pracę z kodem.
