Olen olnud esiotsa arenduses piisavalt kaua, et näha aastate jooksul suundumust: nooremad arendajad töötavad uue programmeerimisparadigmaga, mõistmata selle ajaloolist konteksti. Muidugi on täiesti arusaadav, kui midagi ei tea. Veeb on väga suur koht, kus on palju erinevaid oskusi ja erialasid ning me ei tea alati seda, mida me ei tea. Selles valdkonnas õppimine on pigem pidev teekond, mitte midagi, mis juhtub üks kord ja lõpeb. Näide: keegi minu meeskonnast küsis, kas on võimalik kindlaks teha, kas kasutajad navigeerivad kasutajaliidese teatud vahekaardilt eemale. Juhtisin tähelepanu JavaScripti enne unload sündmusele. Kuid need, kes on selle probleemiga varem tegelenud, teavad, et see on võimalik, kuna neid on tabanud hoiatused teistel saitidel salvestamata andmete kohta, mille puhul enne unload on tüüpiline kasutusjuht. Samuti juhtisin kolleegile tähelepanu lehePeida ja nähtavusChange sündmustele. Kuidas ma sellest teadsin? Sest see tuli päevakorda mõnes teises projektis, mitte sellepärast, et ma JavaScripti algselt õppides sellega tutvusin. Fakt on see, et kaasaegsed esiotsa raamistikud seisavad neile eelnenud tehnoloogiagigantide õlul. Need abstraktsed arendustavad, sageli parema arendajakogemuse saavutamiseks, mis vähendab või isegi välistab vajaduse teada või puudutada traditsiooniliselt olulisi esiotsa kontseptsioone, mida kõik ilmselt teadma peaksid. Mõelge CSS-i objektimudelile (CSSOM). Võib eeldada, et kõigil, kes töötavad CSS-i ja JavaScriptiga, on palju praktilisi CSSOM-i kogemusi, kuid see ei pruugi alati nii olla. Seal oli Reacti projekt e-kaubanduse saidi jaoks, mille kallal ma töötasin, kus meil oli vaja laadida praegu valitud makseteenuse pakkuja stiilitabel. Probleem seisnes selles, et laaditabel laaditi igal lehel, kui seda vajati ainult konkreetsel lehel. Arendaja, kelle ülesandeks oli see teoks teha, polnud kunagi laaditabelit dünaamiliselt laadinud. Jällegi on see täiesti arusaadav, kui React võtab ära traditsioonilise lähenemisviisi, mille poole võisite jõuda. CSSOM pole tõenäoliselt midagi, mida oma igapäevatöös vajate. Kuid on tõenäoline, et peate sellega mingil hetkel suhtlema, isegi kui see on üksikjuhtum. Need kogemused inspireerisid mind seda artiklit kirjutama. Looduses on palju olemasolevaid veebifunktsioone ja -tehnoloogiaid, mida te ei pruugi oma igapäevases töös kunagi puudutada. Võib-olla olete veebiarenduses üsna uus ja pole neist lihtsalt teadlik, kuna olete imbunud konkreetse raamistiku abstraktsioonist, mis ei nõua teilt selle sügavat tundmist või isegi üldse mitte. Ma räägin konkreetselt XML-ist, mida paljud meist teavad, et see on iidne keel, mis ei erine HTML-ist täielikult. Toon selle esile hiljutiste WHATWG-arutelude tõttu, mis viitavad sellele, et märkimisväärne osa XML-virust, mida tuntakse XSLT-programmeerimisena, tuleks brauseritest eemaldada. See on täpselt selline vanem, olemasolev tehnoloogia, mis on meil aastaid olnud ja mida saaks kasutada millekski nii praktiliseks kui minu meeskonna CSSOM-i olukord. Kas olete XSLT-ga varem töötanud? Vaatame, kas toetume tugevalt sellele vanemale tehnoloogiale ja kasutame selle funktsioone väljaspool XML-i konteksti, et lahendada tänapäeval reaalseid probleeme. XPath: keskne API Kõige olulisem XML-tehnoloogia, mis on võib-olla kõige kasulikum väljaspool otsest XML-perspektiivi, on XPath, päringukeel, mis võimaldab teil leida märgistuspuust mis tahes sõlme või atribuudi ühe juurelemendiga. Mul on XSLT vastu isiklik kiindumus, kuid see tugineb ka XPathile ja isiklik kiindumus tuleb tähtsuse järjestamisel kõrvale jätta. XSLT eemaldamise argument ei maini XPathi, seega arvan, et see on siiski lubatud. See on hea, sest XPath on selle tehnoloogiakomplekti keskne ja kõige olulisem API, eriti kui proovite leida midagi, mida kasutada väljaspool tavapärast XML-i kasutust. See on oluline, sest kuigi CSS-i valijaid saab kasutada enamiku teie lehel olevate elementide leidmiseks, ei leia nad neid kõiki. Lisaks ei saa CSS-i valijaid kasutada elemendi leidmiseks selle praeguse asukoha alusel DOM-is. XPath saab. Mõned teist, kes seda loevad, võivad XPathi tunda ja mõned mitte. XPath on päris suur tehnoloogiavaldkond ja ma ei saa tegelikult õpetada kõiki põhitõdesid ja näidata teile ka lahedaid asju, mida sellega teha ühes sellises artiklis. Ma tegelikult proovisin seda artiklit kirjutada, kuid Smashing Magazine'i keskmine väljaanne ei ületa 5000 sõna. Olin juba rohkem kui2000 sõna, olles põhiteadmised alles poole peal. Niisiis, ma hakkan XPathiga lahedaid asju tegema ja annan teile mõned lingid, mida saate põhitõdede jaoks kasutada, kui see kraam teile huvitav tundub. XPathi ja CSS-i kombineerimine XPath saab elementidele päringute tegemisel teha palju asju, mida CSS-i valijad ei suuda. Kuid CSS-i valijad saavad teha ka mõnda asja, mida XPath ei saa, nimelt päringu elemente klassi nime järgi.
CSS XPath .myClass /*[sisaldab(@klass, "minuklass")]
Selles näites küsib CSS elemente, mis sisaldavad .myClassi klassinime. Vahepeal küsib XPathi näide elemente, mis sisaldavad atribuudiklassi stringiga "myClass". Teisisõnu, see valib elemendid, mille atribuudis on myClass, sealhulgas elemendid .myClass klassinimega, aga ka elemendid, mille stringis on "myClass", näiteks .myClass2. XPath on selles mõttes laiem. Nii et ei. Ma ei väida, et peaksime CSS-i välja viskama ja hakkama XPathi kaudu kõiki elemente valima. See pole asja mõte. Asi on selles, et XPath suudab teha asju, mida CSS ei saa ega võiks ikka väga kasulik olla, kuigi tegemist on brauserivirnas oleva vanema tehnoloogiaga ja ei pruugi esmapilgul tunduda ilmselge. Kasutagem neid kahte tehnoloogiat koos mitte ainult sellepärast, et saame, vaid ka sellepärast, et me õpime selle käigus XPathi kohta midagi, muutes selle teiseks tööriistaks teie virnas – see, mida te ei pruugi teadnud, on seal kogu aeg olemas olnud! Probleem on selles, et JavaScripti meetod document.evaluate ja erinevad päringuvalimise meetodid, mida me JavaScripti CSS-i API-dega kasutame, ei ühildu. Olen loonud meie alustamiseks ühilduva päringu API, kuigi tõsi, ma ei ole sellele palju mõelnud, kuna see on kõrvalekalle sellest, mida me siin teeme. Siin on korduvkasutatava päringukonstruktori üsna lihtne toimiv näide: Vaadake Bryan Rasmusseni pliiatsi päringutXPath [forked]. Olen lisanud dokumendiobjektile kaks meetodit: queryCSSSelectors (mis on sisuliselt querySelectorAll) ja queryXPaths. Mõlemad tagastavad queryResults objekti:
{ päringu tüüp: sõlmed | string | number | boolean, tulemused: mis tahes[] // html-elemendid, xml-elemendid, stringid, numbrid, tõeväärtused, queryCSSSelectors: (päring: string, muutke: tõeväärtus) => queryResults, queryXpaths: (päring: string, muutke: tõeväärtus) => queryResults }
Funktsioonid queryCSSSelectors ja queryXpaths käitavad päringut, mille neile annate tulemuste massiivi elementide kohal, kui tulemuste massiiv on loomulikult sõlme tüüpi. Vastasel juhul tagastab see queryResult tühja massiivi ja teatud tüüpi sõlmedega. Kui atribuut amend on seatud väärtusele Tõene, muudavad funktsioonid ise oma päringutulemusi. Mitte mingil juhul ei tohi seda tootmiskeskkonnas kasutada. Ma teen seda ainult selleks, et demonstreerida kahe päringu API koos kasutamise erinevaid mõjusid. Näidispäringud Tahan näidata mõnda näidet erinevatest XPathi päringutest, mis näitavad mõningaid võimsaid asju, mida nad saavad teha ja kuidas neid saab kasutada muude lähenemisviiside asemel. Esimene näide on //li/text(). See küsib kõiki li elemente ja tagastab nende tekstisõlmed. Niisiis, kui peaksime esitama päringu järgmise HTML-i kohta:
- üks
- kaks
- kolm
…see on see, mis tagastatakse:
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
Teisisõnu saame järgmise massiivi: ["üks", "kaks", "kolm"]. Tavaliselt küsite selle saamiseks li elemente, muudate selle päringu tulemuse massiiviks, vastendate massiivi ja tagastate iga elemendi tekstisõlme. Kuid XPathi abil saame seda teha kokkuvõtlikumalt: document.queryXPaths("//li/text()").tulemused.
Pange tähele, et viis tekstisõlme saamiseks on kasutada text(), mis näeb välja nagu funktsiooni allkiri - ja nii see on. Tagastab elemendi tekstisõlme. Meie näites on märgistuses kolm li elementi, millest igaüks sisaldab teksti ("üks", "kaks" ja "kolm").
Vaatame veel ühte teksti() päringu näidet. Oletame, et see on meie märgistus:
Kirjutame päringu, mis tagastab atribuudi href väärtuse: document.queryXPaths("//a[text() = 'Logi sisse']/@href").tulemused.
See on XPathi päring praeguses dokumendis, nagu viimane näide, kuid seekord tagastame lingi (elemendi) atribuudi href, mis sisaldab teksti "Logi sisse". Tegelik tagasitulemus on ["/login.html"]. XPathi funktsioonide ülevaade XPathi funktsioone on mitu ja te pole tõenäoliselt nendega tuttav. Ma arvan, et on mitmeid, millest tasub teada, sealhulgas järgmised:
starts-withKui tekst algab konkreetse muu tekstinäitega, tagastab starts-with(@href, 'http:') tõene, kui href atribuut algab tähega http:. includeKui tekst sisaldab konkreetset muud tekstinäidet, tagastab include(text(), "Smashing Magazine") tõene, kui tekstisõlm sisaldab kuskil sõnu "Smashing Magazine". count Tagastab arvu, mitu vastet päringule on. Näiteks count(//*[starts-with(@href, 'http:']) tagastab arvu selle kohta, mitu linki kontekstisõlmes sisaldab atribuudiga href elemente, mis sisaldavad http:-iga algavat teksti. alamstringToimib nagu JavaScripti alamstring, välja arvatud juhul, kui edastate stringi argumendina. Näiteks alamstring ("minu tekst", 2, 4) tagastab "y t". alamstring-beforeTagastab stringi osa enne teist stringi. Näiteks substing-befor("my text", " ") tagastab "minu". Samamoodi tagastab substring-before("hi","bye") tühja stringi. substring-afterTagastab stringi osa teise stringi järel. Näiteks substing-after("minu tekst", " ") tagastab "tekst". Samamoodi tagastab substring-after("hi","bye") tühja stringi. normalise-space Tagastab argumendistringi tühikutega, mis on normaliseeritud ees- ja lõpp-tühikute eemaldamise ning tühikumärkide jadade asendamisega ühe tühikuga. notTagastab tõeväärtuse tõene, kui argument on väär, muul juhul väär. true Tagastab tõeväärtuse tõene. falseTagastab tõeväärtuse vale. concat Sama asi mis JavaScript concat, ainult et te ei käivita seda stringi meetodina. Selle asemel sisestate kõik stringid, mida soovite ühendada. string-lengthSee ei ole sama mis JavaScripti string-length, vaid pigem tagastab argumendina antud stringi pikkuse. translateThis võtab stringi ja muudab teise argumendi kolmandaks. Näiteks translate("abcdef", "abc", "XYZ") väljastab XYZdef.
Peale nende konkreetsete XPathi funktsioonide on mitmeid muid funktsioone, mis töötavad täpselt samamoodi nagu nende JavaScripti vasted – või põhimõtteliselt igas programmeerimiskeeles olevad vasted –, mis on tõenäoliselt kasulikud, näiteks põrand, lagi, ümmargune, summa jne. Järgmine demo illustreerib kõiki neid funktsioone: Vaadake Bryan Rasmusseni Pen XPath numbrilisi funktsioone [kahveldatud]. Pange tähele, et nagu enamik stringidega manipuleerimise funktsioone, kasutavad paljud numbrilised funktsioonid ühte sisendit. Seda muidugi seetõttu, et neid peaks kasutama päringute tegemiseks, nagu eelmises XPathi näites: //li[põrand(tekst()) > 250]/@val
Kui kasutate neid, nagu enamiku näidete puhul, käivitate selle esimeses sõlmes, mis vastab teele. On ka mõningaid tüübiteisendusfunktsioone, mida peaksite ilmselt vältima, kuna JavaScriptil on juba oma tüübiteisendusprobleemid. Kuid võib juhtuda, et soovite stringi arvuks teisendada, et võrrelda seda mõne teise numbriga. Funktsioonid, mis määravad millegi tüübi, on tõeväärtus, arv, string ja sõlm. Need on olulised XPathi andmetüübid. Ja nagu võite ette kujutada, saab enamikku neist funktsioonidest kasutada andmetüüpides, mis ei ole DOM-i sõlmed. Näiteks alamstring-after võtab stringi, nagu oleme juba käsitlenud, kuid see võib olla atribuudi href string. See võib olla ka lihtsalt string:
const testSubstringAfter = document.queryXPaths("substring-after('tere maailm',' ')");
Ilmselgelt annab see näide meile tulemuste massiivi kui ["maailm"]. Selle tegevuse näitamiseks tegin demolehe, mis kasutab funktsioone asjade vastu, mis ei ole DOM-i sõlmed: Vaadake Bryan Rasmusseni pliiatsi päringutXPath [forked]. Peaksite märkima tõlkefunktsiooni üllatavat aspekti, mis seisneb selles, et kui teises argumendis (st tõlgitavate märkide loendis) on märk ja ühtegi sobivat märki, millele tõlkida, eemaldatakse see märk väljundist. Seega see:
translate('Tere, minu nimi on Inigo Montoya, sa tapsid mu isa, valmistu surema','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…tulemused stringis, sealhulgas tühikud: [" * * ** "]
See tähendab, et täht "a" tõlgitakse tärniks (*), kuid kõik teised märgid, millel pole sihtstringi tõlget, eemaldatakse täielikult. Meil on jäänud vaid tühiktõlgitud "a" tähemärkide vahel. Siis jälle see päring:
translate('Tere, minu nimi on Inigo Montoya, sa tapsid mu isa, valmistu surema','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************'))
…tal pole probleemi ja ta annab tulemuse, mis näeb välja selline:
"****** *** **** ** ***** ******* *** ****** ** ****** ******* *** ***"
Võib teile silma jääda, et JavaScriptis pole lihtsat viisi teha täpselt seda, mida teeb XPathi tõlkefunktsioon, kuigi paljudel juhtudel saab sellega hakkama ka kõigi regulaaravaldistega asendamine. Võite kasutada sama lähenemisviisi, mida ma demonstreerisin, kuid see pole optimaalne, kui soovite ainult stringe tõlkida. Järgmine demo murrab XPathi tõlkefunktsiooni, et pakkuda JavaScripti versiooni: Vaadake Bryan Rasmusseni funktsiooni Pen translate [forked]. Kus saaks midagi sellist kasutada? Kaaluge Caesari šifri krüptimist kolmekohalise nihkega (nt tipptasemel krüptimine aastast 48 eKr):
translate("Caesar plaanib ületada Rubiconi!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Sisendtekst "Caesar plaanib ületada Rubiconi!" tulemuseks on "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Et tuua veel üks kiire näide erinevatest võimalustest, tegin metallifunktsiooni, mis võtab stringi sisendi ja kasutab teksti tagastamiseks tõlkefunktsiooni, kaasa arvatud kõik märgid, mis võtavad umlauti. Vaadake Bryan Rasmusseni pliiatsi metalli funktsiooni [kahveldatud].
const metall = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Ja kui antakse tekst "Motley Crue rule, rock on dudes!", tagastab "Mötley Crüe rüles, röck ön düdes!" Ilmselgelt võib seda funktsiooni paroodiliselt kasutada. Kui see olete teie, peaks see TVTropesi artikkel pakkuma teile palju inspiratsiooni. CSS-i kasutamine XPathiga Pidage meeles meie peamist põhjust CSS-i selektorite koos XPathi kasutamisega: CSS mõistab üsna palju, mis on klass, samas kui XPathiga saab kõige paremini võrrelda klassi atribuudi stringe. See toimib enamikul juhtudel. Kui aga satuksid olukorda, kus näiteks keegi lõi klassid nimega .primaryLinks ja .primaryLinks2 ning kasutate XPathi klassi .primaryLinks hankimiseks, tekiks tõenäoliselt probleeme. Niikaua kui midagi nii rumalat pole, kasutaksite tõenäoliselt XPathi. Kuid mul on kurb teatada, et olen töötanud kohtades, kus inimesed teevad seda tüüpi rumalaid asju. Siin on veel üks demo, mis kasutab koos CSS-i ja XPathi. See näitab, mis juhtub, kui kasutame koodi XPathi käivitamiseks kontekstisõlmes, mis ei ole dokumendi sõlm. Vaadake Pen css ja xpath koos [kahveldatud] Bryan Rasmussen. CSS-päring on .relatedarticles a, mis toob kaks a elementi divisis, millele on määratud klass .relatedarticles. Pärast seda on kolm "halba" päringut, st päringud, mis ei tee seda, mida me tahame, et nad teeksid nende elementide kontekstisõlmena. Ma võin selgitada, miks nad käituvad teisiti, kui võite oodata. Kõnealused kolm halba päringut on järgmised:
//text(): tagastab kogu dokumendi teksti. //a/text(): Tagastab kogu teksti linkide sees dokumendis. ./a/text(): ei tagasta tulemusi.
Nende tulemuste põhjuseks on see, et kuigi teie kontekst on CSS-i päringust tagastatud element, on // vastuolus kogu dokumendiga. See on XPathi tugevus; CSS ei saa minna sõlmest kuni esivanemani ja seejärel selle esivanema õe-vennani ning minna selle õe-venna järeltulijani. Kuid XPath saab. Vahepeal pärib ./ praeguse sõlme lapsi, kus punkt (.) tähistab praegust sõlme ja kaldkriips (/) tähistab minekut mõnda alamsõlme - selle, kas see on atribuut, element või tekst, määrab tee järgmine osa. Kuid CSS-i päringuga valitud alamelement puudub, seega ei tagasta see päring samuti midagi. Viimases demos on kolm head päringut:
.//text(), ./text(), normalise-space(./text()).
Normaliseerimisruumi päring demonstreerib XPathi funktsiooni kasutamist, kuid parandab ka teistes päringutes sisalduva probleemi. HTML on üles ehitatud järgmiselt:
Funktsioonide testimise automatiseerimine Selenium WebDriveri abil
Päring tagastab reavahetuse tekstisõlme alguses ja lõpus,ja normaliseerimisruum eemaldab selle. Mis tahes XPathi funktsiooni kasutamine, mis tagastab midagi muud kui tõeväärtus koos sisendiga XPath, kehtib ka teistele funktsioonidele. Järgmine demo näitab mitmeid näiteid. Vaadake Bryan Rasmusseni funktsioonide Pen xpath näiteid [forked]. Esimene näide näitab probleemi, millele peaksite tähelepanu pöörama. Täpsemalt järgmine kood:
document.queryXPaths("substring-after(//a/@href,'https://')");
…tagastab ühe stringi:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
See on loogiline, eks? Need funktsioonid ei tagasta massiive, vaid pigem üksikuid stringe või üksikuid numbreid. Funktsiooni käivitamine kõikjal, kus on mitu tulemust, tagastab ainult esimese tulemuse. Teine tulemus näitab, mida me tegelikult tahame:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Mis tagastab kahest stringist koosneva massiivi:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPathi funktsioone saab pesastada täpselt nagu JavaScripti funktsioone. Seega, kui teame Smashing Magazine'i URL-i struktuuri, võiksime teha järgmist (soovitatav on kasutada malliliteraale): `tõlgi ( alamstring( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')".
See muutub natuke liiga keeruliseks, kuna vajab kommentaare, mis kirjeldavad, mida see teeb: võtke kogu URL atribuudist href pärast www.smashingmagazine.com/, eemaldage esimesed üheksa tähemärki ja seejärel tõlkige kaldkriips (/) tühjaks, et vabaneda lõppevast kaldkriipsust. Saadud massiiv:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Veel XPathi kasutusjuhtumeid XPath võib testimisel tõeliselt särada. Põhjust pole raske mõista, kuna XPathi saab kasutada DOM-i kõigi elementide hankimiseks DOM-i mis tahes positsioonist, samas kui CSS-i ei saa. Te ei saa loota, et CSS-klassid jäävad paljudes kaasaegsetes ehitussüsteemides järjepidevaks, kuid XPathi abil suudame luua kindlamaid vasteid selle kohta, milline on elemendi tekstisisu, olenemata muutuvast DOM-i struktuurist. On uuritud tehnikaid, mis võimaldavad teil teha vastupidavaid XPathi teste. Miski pole hullem, kui testid katkevad ja ebaõnnestuvad lihtsalt seetõttu, et CSS-i valija enam ei tööta, kuna midagi on ümber nimetatud või eemaldatud. XPath sobib suurepäraselt ka mitme lokaatori eraldamiseks. XPathi päringuid saab elemendi sobitamiseks kasutada rohkem kui ühel viisil. Sama on ka CSS-iga. Kuid XPathi päringud võivad asjadesse süveneda sihipärasemalt, mis piirab tagastatavat, võimaldades teil leida konkreetse vaste, kus võib olla mitu võimalikku vastet. Näiteks saame XPathi abil tagastada konkreetse h2 elemendi, mis sisaldub div sees, mis järgneb kohe sibling-div, mis omakorda sisaldab alamkujutise elementi atribuudiga data-testID="leader":
ära saa seda pealkirja
Ära saa ka seda pealkirja
Juhipildi päis
See on päring: document.queryXPaths(` //div[ next-sibling::div[1] /img[@data-testID='liider'] ] /h2/ tekst() `);
Vaatame demo, et näha, kuidas see kõik kokku saab: Vaadake Bryan Rasmusseni Pen Complex H2 päringut [kahveldatud]. Nii et jah. XPathi kasutades on testi mis tahes elemendini palju võimalikke teid. XSLT 1.0 aegumine Mainisin juba varakult, et Chrome'i meeskond kavatseb brauserist XSLT 1.0 toe eemaldada. See on oluline, kuna XSLT 1.0 kasutab dokumentide teisendamiseks XML-keskset programmeerimist, mis omakorda tugineb XPath 1.0-le, mida leidub enamikus brauserites. Kui see juhtub, kaotame XPathi põhikomponendi. Kuid arvestades asjaolu, et XPath on tõesti suurepärane testide kirjutamiseks, on minu arvates ebatõenäoline, et XPath tervikuna niipea kaob. Sellegipoolest olen märganud, et inimesed hakkavad funktsiooni vastu huvi tundma, kui see ära võetakse. Ja see kehtib kindlasti ka juhul, kui XSLT 1.0 on aegunud. Hacker Newsis toimub terve arutelu, mis on täis argumente amortisatsiooni vastu. Postitus ise on suurepärane näide XSLT-ga ajaveebiraamistiku loomisest. Sinasaate seda arutelu ise lugeda, kuid see puudutab seda, kuidas JavaScripti saab kasutada XLST-i jaoks selliste juhtumite lahendamiseks. Olen näinud ka soovitusi, et brauserid peaksid kasutama SaxonJS-i, mis on port JavaScripti Saxon XSLT, XQUERY ja XPathi mootoritele. See on huvitav idee, eriti kuna Saxon-JS rakendab nende spetsifikatsioonide praegust versiooni, samas kui pole ühtegi brauserit, mis rakendaks XPathi või XSLT versiooni üle 1.0, ega ühtegi brauserit, mis rakendaks XQueryt. Võtsin ühendust Norm Tovey-Walshiga Saxonicas, SaxonJS-i ja teiste Saxoni mootori versioonide taga oleva ettevõttega. Ta ütles: "Kui mõni brauserimüüja oleks huvitatud SaxonJS-ist kui lähtepunktist kaasaegsete XML-tehnoloogiate brauserisse integreerimiseks, oleks meil hea meel seda nendega arutada." - Norm Tovey-Walsh
Aga lisas ka: "Ma oleksin väga üllatunud, kui keegi arvaks, et SaxonJS-i võtmine praegusel kujul ja muutmata kujul brauseri ehitamisse lisamine oleks ideaalne lähenemine. Brauseri müüja, kuna ta loob brauseri, võiks läheneda integratsioonile palju sügavamal tasemel, kui me suudame "väljastpoolt"." - Norm Tovey-Walsh
Väärib märkimist, et Tovey-Walshi kommentaarid tulid umbes nädal enne XSLT amortisatsiooniteadet. Järeldus Võiksin jätkata ja jätkata. Kuid ma loodan, et see on näidanud XPathi võimsust ja andnud teile palju näiteid, kuidas seda kasutada suurte asjade saavutamiseks. See on suurepärane näide brauserivirnas olevast vanemast tehnoloogiast, millel on tänapäevalgi palju kasulikke omadusi, isegi kui te pole kunagi teadnud selle olemasolust või pole kunagi mõelnud selle järele jõuda. Edasine Lugemine
Maroun Ayli, Youssef Bakouny, Nader Jalloul ja Rima Kilany „Automatiseeritud veebitestide vastupidavuse suurendamine loomuliku keelega” (ACM digitaalne raamatukogu)See artikkel pakub palju XPathi näiteid vastupidavate testide kirjutamiseks. XPath (MDN)See on suurepärane koht alustamiseks, kui soovite tehnilist selgitust XPathi toimimise kohta. XPathi õpetus (ZVON) Olen leidnud, et see õpetus on minu enda õppimisel kõige kasulikum tänu rohketele näidetele ja selgetele selgitustele. XPatherSee interaktiivne tööriist võimaldab teil koodiga otse töötada.
