Ek was lank genoeg in front-end ontwikkeling om 'n neiging oor die jare te sien: jonger ontwikkelaars wat met 'n nuwe paradigma van programmering werk sonder om die historiese konteks daarvan te verstaan. Dit is natuurlik heeltemal verstaanbaar om iets nie te weet nie. Die web is 'n baie groot plek met 'n diverse stel vaardighede en spesialiteite, en ons weet nie altyd wat ons nie weet nie. Leer in hierdie veld is 'n voortdurende reis eerder as iets wat een keer gebeur en eindig. Geval in punt: Iemand in my span het gevra of dit moontlik is om te sien of gebruikers weg van 'n spesifieke oortjie in die UI navigeer. Ek het JavaScript se beforeunload-geleentheid uitgewys. Maar diegene wat dit voorheen aangepak het, weet dit is moontlik omdat hulle met waarskuwings getref is oor ongestoorde data op ander werwe, waarvoor vooraflaai 'n tipiese gebruiksgeval is. Ek het ook die pageHide and visibilityChange-gebeurtenisse vir goeie maatreël aan my kollega uitgewys. Hoe het ek daarvan geweet? Omdat dit in 'n ander projek ter sprake gekom het, nie omdat ek dit bestudeer het toe ek aanvanklik JavaScript geleer het nie. Die feit is dat moderne front-end-raamwerke op die skouers staan van die tegnologiereuse wat hulle voorafgegaan het. Hulle abstraheer ontwikkelingspraktyke, dikwels vir 'n beter ontwikkelaarervaring wat die behoefte om te weet of aan te raak wat tradisioneel noodsaaklike voorkantkonsepte was wat almal waarskynlik behoort te weet verminder, of selfs uitskakel. Oorweeg die CSS Object Model (CSSOM). U kan verwag dat enigiemand wat in CSS en JavaScript werk, 'n klomp praktiese CSSOM-ervaring het, maar dit gaan nie altyd die geval wees nie. Daar was 'n React-projek vir 'n e-handelswerf waaraan ek gewerk het waar ons 'n stylblad vir die tans gekose betalingsverskaffer moes laai. Die probleem was dat die stylblad op elke bladsy gelaai het wanneer dit net regtig op 'n spesifieke bladsy nodig was. Die ontwikkelaar wat die taak gehad het om dit te laat gebeur, het nog nooit 'n stylblad dinamies gelaai nie. Weereens, dit is heeltemal te verstane wanneer React die tradisionele benadering waarna u moontlik bereik het, wegtrek. Die CSSOM is waarskynlik nie iets wat jy nodig het in jou alledaagse werk nie. Maar dit is waarskynlik dat jy een of ander tyd daarmee sal moet omgaan, selfs in 'n eenmalige geval. Hierdie ervarings het my geïnspireer om hierdie artikel te skryf. Daar is baie bestaande webkenmerke en -tegnologie in die natuur waaraan jy nooit direk in jou daaglikse werk mag raak nie. Miskien is jy redelik nuut in webontwikkeling en is jy eenvoudig onbewus daarvan, want jy is deurdrenk met die abstraksie van 'n spesifieke raamwerk wat nie vereis dat jy dit diep, of selfs glad nie, moet weet. Ek praat spesifiek oor XML, wat baie van ons weet 'n antieke taal is wat nie heeltemal verskil van HTML nie. Ek bring dit ter sprake as gevolg van onlangse WHATWG-besprekings wat daarop dui dat 'n beduidende deel van die XML-stapel bekend as XSLT-programmering van blaaiers verwyder moet word. Dit is presies die soort ouer, bestaande tegnologie wat ons al jare het wat gebruik kan word vir iets so prakties soos die CSSOM-situasie waarin my span was. Het jy al voorheen met XSLT gewerk? Kom ons kyk of ons baie na hierdie ouer tegnologie leun en die kenmerke daarvan buite die konteks van XML gebruik om werklike probleme vandag aan te pak. XPath: Die sentrale API Die belangrikste XML-tegnologie wat miskien die bruikbaarste buite 'n reguit XML-perspektief is, is XPath, 'n navraagtaal wat jou toelaat om enige nodus of kenmerk in 'n opmaakboom met een wortelelement te vind. Ek het 'n persoonlike liefde vir XSLT, maar dit maak ook staat op XPath, en persoonlike liefde moet opsy gesit word in rangorde belangrikheid. Die argument vir die verwydering van XSLT maak geen melding van XPath nie, so ek veronderstel dit word steeds toegelaat. Dit is goed, want XPath is die sentrale en belangrikste API in hierdie reeks tegnologieë, veral wanneer jy iets probeer vind om buite normale XML-gebruik te gebruik. Dit is belangrik, want hoewel CSS-keurders gebruik kan word om die meeste van die elemente op jou bladsy te vind, kan hulle nie almal vind nie. Verder kan CSS-keurders nie gebruik word om 'n element op grond van sy huidige posisie in die DOM te vind nie. XPath kan. Nou, sommige van julle wat dit lees, ken dalk XPath, en sommige dalk nie. XPath is 'n redelik groot gebied van tegnologie, en ek kan nie regtig al die basiese beginsels leer en ook vir jou oulike dinge wys om daarmee te doen in 'n enkele artikel soos hierdie nie. Ek het eintlik probeer om daardie artikel te skryf, maar die gemiddelde Smashing Magazine-publikasie strek nie meer as 5 000 woorde nie. Ek was al by meer as2 000 woorde terwyl dit net halfpad deur die basiese beginsels is. So, ek gaan oulike goed met XPath begin doen en vir jou 'n paar skakels gee wat jy vir die basiese beginsels kan gebruik as jy hierdie goed interessant vind. Die kombinasie van XPath en CSS XPath kan baie dinge doen wat CSS-keurders nie kan doen wanneer elemente navraag gedoen word nie. Maar CSS-keurders kan ook 'n paar dinge doen wat XPath nie kan doen nie, naamlik navraag na elemente volgens klasnaam.
CSS XPath .myKlas /*[bevat(@klas, "myKlas")]
In hierdie voorbeeld doen CSS navrae na elemente wat 'n .myClass-klasnaam bevat. Intussen vra die XPath-voorbeeld na elemente wat 'n kenmerkklas bevat met die string "myClass". Met ander woorde, dit kies elemente met myClass in enige kenmerk, insluitend elemente met die .myClass-klasnaam – sowel as elemente met “myClass” in die string, soos .myClass2. XPath is breër in daardie sin. So, nee. Ek stel nie voor dat ons CSS moet weggooi en alle elemente via XPath moet begin kies nie. Dit is nie die punt nie. Die punt is dat XPath dinge kan doen wat CSS nie kan en nog steeds baie nuttig kan wees nie, alhoewel dit 'n ouer tegnologie in die blaaierstapel is en met die eerste oogopslag dalk nie voor die hand liggend lyk nie. Kom ons gebruik die twee tegnologieë saam nie net omdat ons kan nie, maar omdat ons in die proses iets oor XPath sal leer, wat dit nog 'n instrument in jou stapel maak - een wat jy dalk nie geweet het nie, was al die tyd daar! Die probleem is dat JavaScript se document.evaluate-metode en die verskeie navraagkiesermetodes wat ons met die CSS API's vir JavaScript gebruik, onversoenbaar is. Ek het 'n versoenbare navrae-API gemaak om ons aan die gang te kry, maar ek het toegegee, ek het nie baie daaraan gedink nie, aangesien dit 'n afwyking is van wat ons hier doen. Hier is 'n redelik eenvoudige werkende voorbeeld van 'n herbruikbare navraagkonstruktor: Sien die Pen-queryXPath [gevurk] deur Bryan Rasmussen. Ek het twee metodes op die dokumentvoorwerp bygevoeg: queryCSSSelectors (wat in wese querySelectorAll is) en queryXPaths. Albei hierdie gee 'n queryResults-objek terug:
{ queryType: nodes | tou | nommer | boolean, resultate: enige[] // html-elemente, xml-elemente, stringe, getalle, booleans, queryCSSSelectors: (navraag: string, wysig: boolean) => queryResults, queryXpaths: (navraag: string, wysig: boolean) => queryResults }
Die queryCSSSelectors en queryXpaths-funksies voer die navraag wat jy aan hulle gee oor die elemente in die resultate-skikking, solank die resultate-skikking natuurlik van tipe nodes is. Andersins sal dit 'n queryResult met 'n leë skikking en 'n tipe nodusse terugstuur. As die wysig-eienskap op waar gestel is, sal die funksies hul eie queryResults verander. Dit moet onder geen omstandighede in 'n produksie-omgewing gebruik word nie. Ek doen dit bloot op hierdie manier om die verskillende effekte van die gebruik van die twee navraag-API's saam te demonstreer. Voorbeeld navrae Ek wil 'n paar voorbeelde van verskillende XPath-navrae wys wat sommige van die kragtige dinge wat hulle kan doen demonstreer en hoe hulle in die plek van ander benaderings gebruik kan word. Die eerste voorbeeld is //li/text(). Dit bevraagteken alle li-elemente en gee hul teksnodusse terug. Dus, as ons die volgende HTML sou vra:
- een
- twee
- drie
…dit is wat teruggestuur word:
{"queryType":"xpathEvaluate","results":["een","twee","drie"],"resultType":"string"}
Met ander woorde, ons kry die volgende skikking: ["een","twee","drie"]. Normaalweg sal jy navraag doen vir die li-elemente om dit te kry, die resultaat van daardie navraag in 'n skikking verander, die skikking karteer en die teksnodus van elke element terugstuur. Maar ons kan dit meer bondig doen met XPath: document.queryXPaths("//li/text()").resultate.
Let daarop dat die manier om 'n teksnodus te kry, is om text() te gebruik, wat lyk soos 'n funksiehandtekening - en dit is. Dit gee die teksnodus van 'n element terug. In ons voorbeeld is daar drie li-elemente in die opmaak, wat elkeen teks bevat ("een", "twee" en "drie").
Kom ons kyk na nog 'n voorbeeld van 'n teks()-navraag. Gestel dit is ons opmerk:
Kom ons skryf 'n navraag wat die href-kenmerkwaarde terugstuur: document.queryXPaths("//a[text() = 'Meld aan']/@href").results.
Dit is 'n XPath-navraag op die huidige dokument, net soos die vorige voorbeeld, maar hierdie keer gee ons die href-kenmerk van 'n skakel ('n element) wat die teks "Sign In" bevat, terug. Die werklike teruggekeerresultaat is ["/login.html"]. XPath-funksies-oorsig Daar is 'n aantal XPath-funksies, en jy is waarskynlik nie daarmee vertroud nie. Daar is verskeie, dink ek, wat die moeite werd is om van te weet, insluitend die volgende:
begin-metAs 'n teks met 'n spesifieke ander teksvoorbeeld begin, gee begin-met(@href, 'http:') waar as 'n href-kenmerk begin met http:. containsAs 'n teks 'n spesifieke ander teksvoorbeeld bevat, bevat contains(text(), "Smashing Magazine") waar as 'n teksnodus enige plek die woorde "Smashing Magazine" daarin bevat. count Gee 'n telling van hoeveel passings daar by 'n navraag is. Byvoorbeeld, count(//*[starts-with(@href, 'http:']) gee 'n telling terug van hoeveel skakels in die konteksnodus elemente het met 'n href-kenmerk wat die teks bevat wat met die http: begin. substringWerk soos JavaScript-substring, behalwe dat jy die string as 'n argument deurgee. Substring("my teks", 2, 4) gee byvoorbeeld "y t" terug. substring-beforeStel die deel van 'n string voor 'n ander string terug. Byvoorbeeld, substing-before("my teks", " ") gee "my" terug. Net so gee substring-before("hi","bye") 'n leë string terug. substring-afterGee die deel van 'n string na 'n ander string terug. Byvoorbeeld, substing-after("my teks", " ") gee "teks" terug. Net so gee substring-after("hi","bye") 'n leë string terug. normaliseer-spasie Gee die argumentstring terug met witspasie wat genormaliseer is deur voorste en agterste witspasie te stroop en reekse witspasiekarakters deur 'n enkele spasie te vervang. gee nie 'n boolean waar as die argument vals is, anders vals. trueGee boolean waar. falseStuur boolean vals terug. concatDieselfde ding as JavaScript concat, behalwe dat jy dit nie as 'n metode op 'n string laat loop nie. In plaas daarvan, plaas jy al die stringe wat jy wil aaneenskakel. string-lengthDit is nie dieselfde as JavaScript string-length nie, maar gee eerder die lengte van die string terug wat dit as 'n argument gegee word. translateThis neem 'n string en verander die tweede argument na die derde argument. Byvoorbeeld, translate("abcdef", "abc", "XYZ") voer XYZdef uit.
Afgesien van hierdie spesifieke XPath-funksies, is daar 'n aantal ander funksies wat net dieselfde werk as hul JavaScript-eweknieë - of eweknieë in basies enige programmeertaal - wat jy waarskynlik ook nuttig sal vind, soos vloer, plafon, rond, som, ensovoorts. Die volgende demonstrasie illustreer elk van hierdie funksies: Sien die Pen XPath Numeriese funksies [gevurk] deur Bryan Rasmussen. Let daarop dat, soos die meeste van die string manipulasie funksies, baie van die numeriese een neem 'n enkele invoer. Dit is natuurlik omdat hulle veronderstel is om vir navrae gebruik te word, soos in die laaste XPath-voorbeeld: //li[vloer(teks()) > 250]/@val
As jy dit gebruik, soos die meeste van die voorbeelde doen, sal jy dit uiteindelik op die eerste nodus laat loop wat by die pad pas. Daar is ook 'n paar tipe omskakelingsfunksies wat u waarskynlik moet vermy omdat JavaScript reeds sy eie tipe omskakelingsprobleme het. Maar daar kan tye wees wanneer jy 'n string na 'n nommer wil omskakel om dit teen 'n ander nommer te kontroleer. Funksies wat die tipe van iets stel, is boolean, getal, string en nodus. Dit is die belangrike XPath-datatipes. En soos jy jou dalk kan voorstel, kan die meeste van hierdie funksies gebruik word op datatipes wat nie DOM-nodes is nie. Substring-after neem byvoorbeeld 'n string soos ons reeds gedek het, maar dit kan die string van 'n href-kenmerk wees. Dit kan ook net 'n string wees:
const testSubstringAfter = document.queryXPaths("substring-after('hallo wêreld',' ')");
Dit is duidelik dat hierdie voorbeeld vir ons die resultate-skikking sal teruggee as ["wêreld"]. Om dit in aksie te wys, het ek 'n demonstrasiebladsy gemaak met funksies teen dinge wat nie DOM-nodes is nie: Sien die Pen-queryXPath [gevurk] deur Bryan Rasmussen. Jy moet let op die verrassende aspek van die vertaalfunksie, wat is dat as jy 'n karakter in die tweede argument het (d.w.s. die lys karakters wat jy wil vertaal) en geen bypassende karakter om na te vertaal nie, word daardie karakter uit die uitvoer verwyder. Dus, hierdie:
translate('Hallo, my naam is Inigo Montoya, jy het my pa vermoor, maak gereed om te sterf','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… lei tot die string, insluitend spasies: [" *** ** "]
Dit beteken dat die letter "a" na 'n asterisk (*) vertaal word, maar elke ander karakter wat nie 'n vertaling het nie, gegewe die teikenstring word heeltemal verwyder. Die witspasie is al wat ons oor hettussen die vertaalde "a" karakters. Dan weer hierdie navraag:
translate('Hallo, my naam is Inigo Montoya, jy het my pa vermoor, maak gereed om te sterf','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************')")
…het nie die probleem nie en lewer 'n resultaat uit wat soos volg lyk:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Dit mag jou tref dat daar geen maklike manier in JavaScript is om presies te doen wat die XPath-vertaalfunksie doen nie, alhoewel vervangAll met gewone uitdrukkings dit vir baie gebruiksgevalle kan hanteer. Jy kan dieselfde benadering gebruik wat ek gedemonstreer het, maar dit is suboptimaal as al wat jy wil hê is om die snare te vertaal. Die volgende demonstrasie sluit XPath se vertaalfunksie in om 'n JavaScript-weergawe te verskaf: Sien die Pen-vertaalfunksie [gevurk] deur Bryan Rasmussen. Waar kan jy so iets gebruik? Oorweeg Caesar Cipher-enkripsie met 'n drie-plek-offset (bv. top-of-the-line enkripsie vanaf 48 v.C.):
translate("Caesar beplan om die Rubicon oor te steek!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Die invoerteks "Caesar beplan om die Rubicon oor te steek!" lei tot “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Om nog 'n vinnige voorbeeld van verskillende moontlikhede te gee, het ek 'n metaalfunksie gemaak wat 'n string-invoer neem en 'n vertaalfunksie gebruik om die teks terug te gee, insluitend alle karakters wat omluide neem. Sien die Pen-metaalfunksie [gevurk] deur Bryan Rasmussen.
const metaal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
En as die teks "Motley Crue reëls, rock on dudes!" gegee word, gee "Mötley Crüe rüles, röck ön düdes!" Uiteraard kan 'n mens allerhande parodie-gebruike van hierdie funksie hê. As dit jy is, dan behoort hierdie TVTropes-artikel jou baie inspirasie te gee. Gebruik CSS met XPath Onthou ons hoofrede om CSS-keurders saam met XPath te gebruik: CSS verstaan nogal wat 'n klas is, terwyl die beste wat jy met XPath kan doen, stringvergelykings van die klaskenmerk is. Dit sal in die meeste gevalle werk. Maar as jy ooit 'n situasie sou ondervind waar, sê, iemand klasse geskep het met die naam .primaryLinks en .primaryLinks2 en jy gebruik XPath om die .primaryLinks-klas te kry, dan sal jy waarskynlik probleme ondervind. Solank daar niks simpel soos dit is nie, sal jy waarskynlik XPath gebruik. Maar ek is hartseer om te rapporteer dat ek by plekke gewerk het waar mense daardie tipe simpel goed doen. Hier is nog 'n demonstrasie wat CSS en XPath saam gebruik. Dit wys wat gebeur wanneer ons die kode gebruik om 'n XPath te laat loop op 'n konteksknoop wat nie die dokument se nodus is nie. Sien die Pen css en xpath saam [gevurk] deur Bryan Rasmussen. Die CSS-navraag is .relatedarticles a, wat die twee a-elemente haal in 'n div wat 'n .relatedarticles-klas toegeken is. Daarna is drie "slegte" navrae, dit wil sê, navrae wat nie doen wat ons wil hê hulle moet doen wanneer hulle met hierdie elemente as die konteksnodus hardloop nie. Ek kan verduidelik hoekom hulle anders optree as wat jy sou verwag. Die drie slegte navrae ter sprake is:
//text(): Wys al die teks in die dokument. //a/text(): Wys al die teks binne-in skakels in die dokument. ./a/text(): Gee geen resultate nie.
Die rede vir hierdie resultate is dat, terwyl jou konteks 'n element is wat van die CSS-navraag teruggestuur word, // teen die hele dokument ingaan. Dit is die krag van XPath; CSS kan nie van 'n nodus na 'n voorouer en dan na 'n broer of suster van daardie voorouer gaan nie, en afstap na 'n afstammeling van daardie broer of suster. Maar XPath kan. Intussen vra ./ die kinders van die huidige nodus, waar die punt (.) die huidige nodus verteenwoordig, en die voorwaartse skuinsstreep (/) verteenwoordig om na een of ander kindernodus te gaan — of dit 'n kenmerk, element of teks is, word bepaal deur die volgende deel van die pad. Maar daar is geen kind 'n element wat deur die CSS-navraag gekies is nie, dus gee daardie navraag ook niks terug nie. Daar is drie goeie navrae in daardie laaste demo:
.//text(), ./teks(), normaliseer-spasie(./text()).
Die normaliseer-spasie-navraag demonstreer XPath-funksiegebruik, maar los ook 'n probleem op wat in die ander navrae ingesluit is. Die HTML is soos volg gestruktureer:
Outomatiseer u kenmerktoetsing met Selenium WebDriver
Die navraag gee 'n lyntoevoer aan die begin en einde van die teksnodus,en normaliseer-spasie verwyder dit. Die gebruik van enige XPath-funksie wat iets anders as 'n boolean met 'n invoer XPath terugstuur, is van toepassing op ander funksies. Die volgende demo toon 'n aantal voorbeelde: Sien die Pen xpath-funksies voorbeelde [gevurk] deur Bryan Rasmussen. Die eerste voorbeeld toon 'n probleem waarvoor jy moet oppas. Spesifiek, die volgende kode:
document.queryXPaths("substring-after(//a/@href,'https://')");
… gee een string terug:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Dit maak sin, reg? Hierdie funksies gee nie skikkings terug nie, maar eerder enkele stringe of enkele getalle. Om die funksie op enige plek met veelvuldige resultate te laat loop, gee net die eerste resultaat. Die tweede resultaat wys wat ons regtig wil hê:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Wat 'n skikking van twee stringe terugstuur:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-funksies kan geneste word net soos funksies in JavaScript. Dus, as ons die Smashing Magazine URL-struktuur ken, kan ons die volgende doen (die gebruik van sjabloonletters word aanbeveel): `vertaal( substring( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Dit raak 'n bietjie te kompleks in die mate dat dit opmerkings nodig het wat beskryf wat dit doen: neem al die URL van die href-kenmerk na www.smashingmagazine.com/, verwyder die eerste nege karakters, vertaal dan die vorentoe-skuinsstreep (/)-karakter na niks om van die einde vorentoe-skuinsstreep ontslae te raak. Die resulterende skikking:
["kenmerk-toets-selenium-webbestuurder","outomatiese-toets-resultate-verbeter-toeganklikheid"]
Meer XPath-gebruiksgevalle XPath kan regtig skitter in toetsing. Die rede is nie moeilik om te sien nie, aangesien XPath gebruik kan word om elke element in die DOM vanaf enige posisie in die DOM te kry, terwyl CSS nie kan nie. U kan nie daarop reken dat CSS-klasse konsekwent bly in baie moderne boustelsels nie, maar met XPath kan ons meer robuuste passings maak oor wat die teksinhoud van 'n element is, ongeag 'n veranderende DOM-struktuur. Daar is navorsing gedoen oor tegnieke wat jou toelaat om veerkragtige XPath-toetse te maak. Niks is erger as om toetse uit te vlok en te misluk net omdat 'n CSS-keurder nie meer werk nie omdat iets hernoem of verwyder is. XPath is ook baie goed vir meervoudige opspoorder onttrekking. Daar is meer as een manier om XPath-navrae te gebruik om 'n element te pas. Dieselfde geld met CSS. Maar XPath-navrae kan op 'n meer geteikende manier in dinge ingaan wat beperk wat teruggestuur word, sodat jy 'n spesifieke passing kan vind waar daar verskeie moontlike passings kan wees. Ons kan byvoorbeeld XPath gebruik om 'n spesifieke h2-element terug te gee wat binne 'n div vervat is wat onmiddellik op 'n broer en suster volg, wat op sy beurt 'n kind-beeldelement bevat met 'n data-testID="leader"-kenmerk daarop:
kry nie hierdie opskrif nie
Kry ook nie hierdie opskrif nie
Die kopskrif vir die leierprent
Dit is die navraag: document.queryXPaths(` //div[ volgende broer::div[1] /img[@data-testID='leier'] ] /h2/ teks() `);
Kom ons loer in 'n demonstrasie om te sien hoe dit alles bymekaar kom: Sien die Pen Complex H2 Query [gevurk] deur Bryan Rasmussen. So, ja. Daar is baie moontlike paaie na enige element in 'n toets wat XPath gebruik. XSLT 1.0 Afskaffing Ek het vroeg genoem dat die Chrome-span van plan is om XSLT 1.0-ondersteuning van die blaaier te verwyder. Dit is belangrik omdat XSLT 1.0 XML-gefokusde programmering gebruik vir dokumenttransformasie wat op sy beurt staatmaak op XPath 1.0, wat in die meeste blaaiers voorkom. Wanneer dit gebeur, sal ons 'n sleutelkomponent van XPath verloor. Maar gegewe die feit dat XPath regtig wonderlik is om toetse te skryf, vind ek dit onwaarskynlik dat XPath as geheel binnekort sal verdwyn. Dit gesê, ek het opgemerk dat mense in 'n kenmerk belangstel wanneer dit weggeneem word. En dit is beslis waar in die geval van XSLT 1.0 wat afgekeur word. Daar is 'n hele bespreking by Hacker News gevul met argumente teen die afskaffing. Die pos self is 'n goeie voorbeeld van die skep van 'n blograamwerk met XSLT. Jykan die bespreking vir jouself lees, maar dit gaan oor hoe JavaScript as 'n shim vir XLST gebruik kan word om daardie soort gevalle te hanteer. Ek het ook voorstelle gesien dat blaaiers SaxonJS moet gebruik, wat 'n poort is na JavaScript se Saxon XSLT-, XQUERY- en XPath-enjins. Dit is 'n interessante idee, veral aangesien Saxon-JS die huidige weergawe van hierdie spesifikasies implementeer, terwyl daar geen blaaier is wat enige weergawe van XPath of XSLT verder as 1.0 implementeer nie, en niemand wat XQuery implementeer nie. Ek het uitgereik na Norm Tovey-Walsh by Saxonica, die maatskappy agter SaxonJS en ander weergawes van die Saxon-enjin. Hy het gesê: "As enige blaaierverkoper belangstel om SaxonJS as 'n beginpunt te neem vir die integrasie van moderne XML-tegnologieë in die blaaier, sal ons verheug wees om dit met hulle te bespreek." - Norm Tovey-Walsh
Maar ook bygevoeg: "Ek sal baie verbaas wees as enigiemand dink dat dit die ideale benadering sou wees om SaxonJS in sy huidige vorm te neem en dit onveranderd in die blaaierbou te laat val. 'n Blaaierverkoper, uit die aard van die feit dat hulle die blaaier bou, kan die integrasie op 'n baie dieper vlak benader as wat ons kan 'van buite af'."— Norm Tovey-Walsh
Dit is opmerklik dat Tovey-Walsh se opmerkings ongeveer 'n week voor die XSLT-afskaffingsaankondiging gekom het. Gevolgtrekking Ek kon aanhou en aanhou. Maar ek hoop dit het die krag van XPath gedemonstreer en vir jou baie voorbeelde gegee wat demonstreer hoe om dit te gebruik om groot dinge te bereik. Dit is 'n perfekte voorbeeld van ouer tegnologie in die blaaierstapel wat vandag nog baie bruikbaarheid het, selfs al het jy nog nooit geweet dat dit bestaan nie of dit nooit oorweeg het om daarna uit te reik nie. Verdere lees
“Verbetering van die veerkragtigheid van outomatiese webtoetse met natuurlike taal” (ACM Digital Library) deur Maroun Ayli, Youssef Bakouny, Nader Jalloul en Rima Kilany Hierdie artikel bied baie XPath-voorbeelde vir die skryf van veerkragtige toetse. XPath (MDN)Hierdie is 'n uitstekende plek om te begin as jy 'n tegniese verduideliking wil hê oor hoe XPath werk. XPath-tutoriaal (ZVON) Ek het gevind dat hierdie tutoriaal die nuttigste is in my eie leer, danksy 'n magdom voorbeelde en duidelike verduidelikings. XPatherHierdie interaktiewe hulpmiddel laat jou direk met die kode werk.
