Yıllar boyunca bir trend görecek kadar uzun süredir ön uç geliştirme içerisindeyim: genç geliştiriciler, bunun tarihsel bağlamını anlamadan yeni bir programlama paradigması ile çalışıyor. Elbette bir şeyi bilmemek son derece anlaşılır bir durumdur. Web, çeşitli beceri ve uzmanlıklara sahip çok büyük bir yer ve neyi bilmediğimizi her zaman bilemeyiz. Bu alanda öğrenme bir kez olup biten bir şey değil, sürekli devam eden bir yolculuktur. Örnek olay: Ekibimden biri, kullanıcıların kullanıcı arayüzündeki belirli bir sekmeden ayrılıp ayrılmadığını anlamanın mümkün olup olmadığını sordu. JavaScript’in beforeunload olayına dikkat çektim. Ancak bununla daha önce uğraşanlar bunun mümkün olduğunu biliyorlar çünkü diğer sitelerdeki kaydedilmemiş verilerle ilgili uyarılarla karşılaştılar; bu, boşaltmadan önce tipik bir kullanım durumudur. Ayrıca, iyi bir önlem almak için meslektaşıma Hide ve görünürlük Değişikliği olaylarını da işaret ettim. Bunu nasıl bildim? Çünkü başka bir projede ortaya çıktı, ilk başta JavaScript öğrenirken üzerinde çalıştığım için değil. Gerçek şu ki, modern ön uç çerçeveler, kendilerinden önceki teknoloji devlerinin omuzlarında duruyor. Genellikle herkesin bilmesi gereken temel ön uç kavramları bilme veya bunlara dokunma ihtiyacını azaltan, hatta ortadan kaldıran daha iyi bir geliştirici deneyimi için geliştirme uygulamalarını soyutlarlar. CSS Nesne Modelini (CSSOM) düşünün. CSS ve JavaScript üzerinde çalışan herkesin uygulamalı CSSOM deneyimine sahip olmasını bekleyebilirsiniz, ancak durum her zaman böyle olmayacaktır. Üzerinde çalıştığım bir e-ticaret sitesi için şu anda seçili ödeme sağlayıcısı için bir stil sayfası yüklememiz gereken bir React projesi vardı. Sorun, stil sayfasının yalnızca belirli bir sayfada gerçekten ihtiyaç duyulduğu halde her sayfaya yüklenmesiydi. Bunu gerçekleştirmekle görevlendirilen geliştirici daha önce dinamik olarak bir stil sayfası yüklememişti. React'ın ulaşmış olabileceğiniz geleneksel yaklaşımı soyutlamasıyla bu durum yine tamamen anlaşılabilir bir durumdur. CSSOM muhtemelen günlük işlerinizde ihtiyacınız olan bir şey değildir. Ancak tek seferlik bir durumda bile muhtemelen bir noktada onunla etkileşime girmeniz gerekecektir. Bu deneyimler bana bu makaleyi yazmaya ilham verdi. Günlük işlerinizde asla doğrudan dokunamayacağınız birçok web özelliği ve teknolojisi mevcuttur. Belki de web geliştirme konusunda oldukça yenisiniz ve bunlardan habersizsiniz çünkü onu derinlemesine bilmenizi gerektirmeyen, hatta hiç gerektirmeyen belirli bir çerçevenin soyutlamasına dalmış durumdasınız. Özellikle, çoğumuzun HTML'den tamamen farklı olmayan eski bir dil olduğunu bildiği XML'den bahsediyorum. Bunu, XSLT programlama olarak bilinen XML yığınının önemli bir bölümünün tarayıcılardan kaldırılması gerektiğini öne süren son WHATWG tartışmaları nedeniyle gündeme getiriyorum. Bu tam olarak yıllardır sahip olduğumuz ve ekibimin içinde bulunduğu CSSOM durumu kadar pratik bir şey için kullanılabilecek daha eski, mevcut bir teknolojidir. Daha önce XSLT ile çalıştınız mı? Bakalım, bu eski teknolojiye yoğun bir şekilde yaslanıp, günümüzün gerçek dünya sorunlarının üstesinden gelmek için onun XML bağlamı dışındaki özelliklerinden yararlanabilecek miyiz? XPath: Merkezi API Düz XML perspektifinin dışında belki de en kullanışlı olan en önemli XML teknolojisi, tek bir kök öğeye sahip bir işaretleme ağacındaki herhangi bir düğümü veya niteliği bulmanızı sağlayan bir sorgu dili olan XPath'tır. XSLT'ye karşı kişisel bir ilgim var ama bu aynı zamanda XPath'a da bağlı ve sıralamanın öneminde kişisel sevginin bir kenara bırakılması gerekiyor. XSLT'yi kaldırma argümanında XPath'tan bahsedilmiyor, dolayısıyla buna hala izin verildiğini düşünüyorum. Bu iyi çünkü XPath, özellikle normal XML kullanımı dışında kullanılacak bir şey bulmaya çalışırken, bu teknoloji paketindeki merkezi ve en önemli API'dir. Bu önemlidir çünkü CSS seçiciler sayfanızdaki öğelerin çoğunu bulmak için kullanılabilse de hepsini bulamazlar. Ayrıca CSS seçiciler, bir öğeyi DOM'daki mevcut konumuna göre bulmak için kullanılamaz. XPath yapabilir. Şimdi, bunu okuyan bazılarınız XPath'ı biliyor olabilir, bazılarınız ise bilmiyor olabilir. XPath oldukça büyük bir teknoloji alanıdır ve bunun gibi tek bir makalede size tüm temel bilgileri öğretemem ve aynı zamanda bununla yapılabilecek harika şeyleri de gösteremem. Aslında o makaleyi yazmayı denedim ama ortalama Smashing Magazine yayını 5.000 kelimeyi geçmiyor. Zaten birden fazla durumdaydımTemel bilgilerin henüz yarısındayken 2.000 kelime. Bu yüzden, XPath ile harika şeyler yapmaya başlayacağım ve bu şeyleri ilginç bulursanız size temel bilgiler için kullanabileceğiniz bazı bağlantılar vereceğim. XPath ve CSS'yi birleştirmek XPath, CSS seçicilerin öğeleri sorgularken yapamadığı birçok şeyi yapabilir. Ancak CSS seçicileri, XPath'ın yapamadığı birkaç şeyi de yapabilir; yani öğeleri sınıf adına göre sorgulamak.
CSS XPath .sınıfım /*[içerir(@sınıf, "sınıfım")]
Bu örnekte CSS, .myClass sınıf adını içeren öğeleri sorgular. Bu arada XPath örneği, "myClass" dizesine sahip bir öznitelik sınıfı içeren öğeleri sorgular. Başka bir deyişle, .myClass sınıf adına sahip öğelerin yanı sıra .myClass2 gibi dizede "myClass" bulunan öğeler de dahil olmak üzere herhangi bir öznitelikte myClass'a sahip öğeleri seçer. XPath bu anlamda daha geniştir. Yani hayır. CSS'yi bir kenara atıp tüm öğeleri XPath aracılığıyla seçmeye başlamamızı önermiyorum. Önemli olan bu değil. Önemli olan şu ki, XPath, tarayıcı yığınında daha eski bir teknoloji olmasına ve ilk bakışta bariz görünmese de, CSS'nin yapamadığı ve hala çok yararlı olabileceği şeyleri yapabilir. İki teknolojiyi birlikte kullanalım çünkü sadece yapabiliyoruz, aynı zamanda bu süreçte XPath hakkında bir şeyler öğreneceğiz ve onu yığınınızdaki başka bir araç haline getireceğiz; bu aracın başından beri orada olduğunu bilemeyebilirsiniz! Sorun, JavaScript'in document.evaluate yönteminin ve JavaScript için CSS API'leriyle kullandığımız çeşitli sorgu seçici yöntemlerinin uyumsuz olmasıdır. Başlamak için uyumlu bir sorgulama API'si hazırladım, ancak kabul etmek gerekir ki bu, burada yaptığımız şeyden farklı bir şey olduğu için üzerinde pek fazla düşünmedim. Yeniden kullanılabilir bir sorgu oluşturucunun oldukça basit çalışan bir örneği: Bryan Rasmussen tarafından kaleme alınan Pen queryXPath'e [çatallı] bakın. Belge nesnesine iki yöntem ekledim: queryCSSSelectors (aslında querySelectorAll'dir) ve queryXPaths. Bunların her ikisi de bir queryResults nesnesi döndürür:
{ queryType: düğümler | dize | sayı | boole, sonuçlar: herhangi[] // html öğeleri, xml öğeleri, dizeler, sayılar, boolean'lar, queryCSSSelectors: (sorgu: string, değişiklik: boolean) => queryResults, queryXpaths: (sorgu: string, değişiklik: boolean) => queryResults }
queryCSSSelectors ve queryXpaths işlevleri, elbette, results dizisi düğüm türünde olduğu sürece, onlara verdiğiniz sorguyu results dizisindeki öğeler üzerinde çalıştırır. Aksi takdirde, boş bir dizi ve bir tür düğüm içeren bir queryResult döndürür. amend özelliği true olarak ayarlanırsa işlevler kendi queryResults'larını değiştirir. Bu hiçbir durumda üretim ortamında kullanılmamalıdır. Bunu yalnızca iki sorgu API'sini birlikte kullanmanın çeşitli etkilerini göstermek için bu şekilde yapıyorum. Örnek Sorgular Yapabilecekleri güçlü şeylerden bazılarını ve diğer yaklaşımların yerine nasıl kullanılabileceğini gösteren farklı XPath sorgularından birkaç örnek göstermek istiyorum. İlk örnek //li/text()'tir. Bu, tüm li öğelerini sorgular ve metin düğümlerini döndürür. Öyleyse, aşağıdaki HTML'yi sorgulayacak olsaydık:
- bir
- iki
- üç
… döndürülen şey budur:
{"queryType":"xpathEvaluate","results":["bir""iki""üç"],"resultType":"string"}
Başka bir deyişle, şu diziyi elde ederiz: ["bir", "iki", "üç"]. Normalde bunu elde etmek için li öğelerini sorgularsınız, bu sorgunun sonucunu bir diziye dönüştürürsünüz, diziyi eşlersiniz ve her öğenin metin düğümünü döndürürsünüz. Ancak bunu XPath ile daha net bir şekilde yapabiliriz: document.queryXPaths("//li/text()").results.
Bir metin düğümü elde etmenin yolunun, işlev imzasına benzeyen text() kullanmak olduğuna dikkat edin ve öyledir. Bir öğenin metin düğümünü döndürür. Örneğimizde, işaretlemede her biri metin içeren üç li öğesi vardır ("bir", "iki" ve "üç").
Text() sorgusunun bir örneğine daha bakalım. Bunun işaretlememiz olduğunu varsayalım:
href öznitelik değerini döndüren bir sorgu yazalım: document.queryXPaths("//a[text() = 'Oturum Aç']/@href").results.
Bu, tıpkı son örnekte olduğu gibi mevcut belgedeki bir XPath sorgusudur, ancak bu sefer “Oturum Aç” metnini içeren bir bağlantının (bir öğenin) href niteliğini döndürüyoruz. Gerçek geri döndüsonuç ["/login.html"] olur. XPath İşlevlerine Genel Bakış Çok sayıda XPath işlevi vardır ve muhtemelen bunlara aşina değilsiniz. Aşağıdakiler de dahil olmak üzere, bilmeye değer birkaç konu olduğunu düşünüyorum:
başlar-withBir metin belirli bir başka metin örneğiyle başlıyorsa, başlar-with(@href, 'http:'), bir href özelliği http: ile başlıyorsa true değerini döndürür. includeBir metin belirli bir başka metin örneği içeriyorsa, include(text(), "Smashing Magazine"), bir metin düğümünün herhangi bir yerinde "Smashing Magazine" sözcüklerini içeriyorsa true değerini döndürür. countBir sorguda kaç eşleşme olduğunun sayısını döndürür. Örneğin, count(//*[starts-with(@href, 'http:']) bağlam düğümünde kaç bağlantının http: ile başlayan metni içeren href niteliğine sahip öğelere sahip olduğunun sayısını döndürür. substring JavaScript substring gibi çalışır, ancak dizeyi argüman olarak iletmeniz dışında. Örneğin substring("metnim", 2, 4), "y t" değerini döndürür. substring-before Bir dizenin başka bir dizeden önceki kısmını döndürür. Örneğin, substing-before("metnim", " ") "benim" ifadesini döndürür. Benzer şekilde, substring-before("hi", "bye") boş bir dize döndürür. substring-afterBir dizenin başka bir dizeden sonraki kısmını döndürür. Örneğin, substing-after("metnim", " ") "metin" değerini döndürür. Benzer şekilde, substring-after("hi", "bye") boş bir dize döndürür. normalize-spaceBaştaki ve sondaki boşlukların çıkarılması ve boşluk karakter dizilerinin tek bir boşlukla değiştirilmesiyle normalleştirilmiş boşluk içeren bağımsız değişken dizesini döndürür. not Bağımsız değişken yanlışsa doğru, değilse yanlış bir boole değeri döndürür. trueBoolean true değerini döndürür. falseBoolean false değerini döndürür. concatJavaScript concat ile aynı şeydir, tek farkı onu bir dizge üzerinde bir yöntem olarak çalıştırmamanızdır. Bunun yerine, birleştirmek istediğiniz tüm dizeleri girersiniz. string-lengthBu, JavaScript string-length ile aynı değildir ancak argüman olarak verilen dizenin uzunluğunu döndürür. TranslateThis bir dize alır ve ikinci argümanı üçüncü argümanla değiştirir. Örneğin, Translate("abcdef", "abc", "XYZ") XYZdef çıktısını verir.
Bu belirli XPath işlevlerinin yanı sıra, JavaScript karşılıklarıyla (veya temelde herhangi bir programlama dilindeki karşılıklarıyla) tamamen aynı şekilde çalışan ve muhtemelen yararlı bulacağınız taban, tavan, yuvarlak, toplam vb. gibi başka işlevler de vardır. Aşağıdaki demo bu işlevlerin her birini göstermektedir: Bryan Rasmussen tarafından yazılan Pen XPath Sayısal işlevlerine [çatallı] bakın. Çoğu dize işleme işlevi gibi, sayısal olanların çoğunun tek bir girdi aldığını unutmayın. Bunun nedeni elbette son XPath örneğinde olduğu gibi sorgulama için kullanılmaları gerektiğidir: //li[kat(metin()) > 250]/@val
Çoğu örnekte olduğu gibi bunları kullanırsanız, onu yolla eşleşen ilk düğümde çalıştırırsınız. Ayrıca muhtemelen kaçınmanız gereken bazı tür dönüştürme işlevleri de vardır, çünkü JavaScript'in zaten kendi tür dönüştürme sorunları vardır. Ancak, bir dizeyi başka bir sayıyla karşılaştırmak için bir sayıya dönüştürmek istediğiniz zamanlar olabilir. Bir şeyin türünü ayarlayan işlevler boolean, sayı, dize ve düğümdür. Bunlar önemli XPath veri türleridir. Ve tahmin edebileceğiniz gibi bu işlevlerin çoğu DOM düğümleri olmayan veri türlerinde kullanılabilir. Örneğin, substring-after daha önce ele aldığımız gibi bir dize alır, ancak bu bir href özelliğinden gelen dize olabilir. Ayrıca yalnızca bir dize de olabilir:
const testSubstringAfter = document.queryXPaths("substring-after('merhaba dünya',' ')");
Açıkçası, bu örnek bize sonuçlar dizisini ["dünya"] olarak geri verecektir. Bunu çalışırken göstermek için, DOM düğümleri olmayan şeylere karşı işlevleri kullanan bir demo sayfası hazırladım: Bryan Rasmussen tarafından kaleme alınan Pen queryXPath'e [çatallı] bakın. Çeviri fonksiyonunun şaşırtıcı yönüne dikkat etmelisiniz; eğer ikinci argümanda bir karakter varsa (yani çevrilmesini istediğiniz karakterlerin listesi) ve çevrilecek eşleşen karakter yoksa, o karakter çıktıdan kaldırılır. Böylece, bu:
Translate('Merhaba, Benim Adım Inigo Montoya, babamı öldürdün, ölmeye hazırlan','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…boşluklar da dahil olmak üzere dizeyle sonuçlanır: [" * * ** "]
Bu, "a" harfinin yıldız işaretine (*) çevrildiği, ancak hedef dizede çevirisi olmayan tüm diğer karakterlerin tamamen kaldırıldığı anlamına gelir. Geriye kalan tek şey boşlukçevrilmiş “a” karakterleri arasında. Sonra tekrar bu sorgu:
Translate('Merhaba, Benim Adım Inigo Montoya, babamı öldürdün, ölmeye hazırlan','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************')")
…sorun yok ve şuna benzeyen bir sonuç çıkıyor:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
JavaScript'te XPath çeviri işlevinin yaptığı şeyi tam olarak yapmanın kolay bir yolu olmadığı dikkatinizi çekebilir, ancak birçok kullanım durumunda, normal ifadelerle değiştirinAll bu işi halledebilir. Gösterdiğim yaklaşımın aynısını kullanabilirsiniz, ancak tek istediğiniz dizeleri çevirmekse bu yetersizdir. Aşağıdaki demo, bir JavaScript sürümü sağlamak için XPath'ın çeviri işlevini tamamlar: Bryan Rasmussen'in kalem çeviri işlevine [çatallı] bakın. Böyle bir şeyi nerede kullanabilirsiniz? Üç basamaklı kaydırmalı Caesar Cipher şifrelemesini düşünün (örneğin, M.Ö. 48'den kalma birinci sınıf şifreleme):
Translate("Sezar Rubicon'u geçmeyi planlıyor!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Giriş metni "Sezar Rubicon'u geçmeyi planlıyor!" "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" ile sonuçlanır Farklı olasılıklara kısa bir örnek daha vermek gerekirse, bir dize girdisi alan ve çift nokta işareti alan tüm karakterler de dahil olmak üzere metni döndürmek için bir çeviri işlevi kullanan bir metal işlevi yaptım. Bryan Rasmussen'in kalem metal fonksiyonuna [çatallı] bakın.
const metal = (str) => { return Translate(str, "AOUaou", "ÄÖÜäöü"); }
Ve eğer "Motley Crue kuralları, sallanın ahbaplar!" metni verilirse, "Mötley Crüe rüles, röck ön düdes!" Açıkçası, bu işlevin her türden parodi kullanımına sahip olabilirsiniz. Eğer bu sizseniz, o zaman bu TVTropes makalesi size bol miktarda ilham sağlamalıdır. CSS'yi XPath ile Kullanmak CSS seçicilerini XPath ile birlikte kullanmamızın ana nedenini unutmayın: CSS, bir sınıfın ne olduğunu hemen hemen anlar, oysa XPath ile yapabileceğiniz en iyi şey, sınıf niteliğinin dize karşılaştırmalarıdır. Bu çoğu durumda işe yarayacaktır. Ancak eğer birisinin .primaryLinks ve .primaryLinks2 adında sınıflar oluşturduğu ve sizin .primaryLinks sınıfını almak için XPath kullandığınız bir durumla karşılaşırsanız, o zaman muhtemelen sorunlarla karşılaşırsınız. Böyle saçma bir şey olmadığı sürece muhtemelen XPath kullanırsınız. Ancak insanların bu tür aptalca şeyler yaptığı yerlerde çalıştığımı söylemekten üzüntü duyuyorum. İşte CSS ve XPath'ı birlikte kullanan başka bir demo. Belgenin düğümü olmayan bir bağlam düğümünde XPath çalıştırmak için kodu kullandığımızda ne olacağını gösterir. Bryan Rasmussen tarafından kalem css ve xpath'i birlikte [çatallanmış] görün. CSS sorgusu .ilişkiliarticles a'dır ve .ilgiliarticles sınıfına atanmış bir div'deki iki a öğesini getirir. Bundan sonra üç "kötü" sorgu gelir, yani bağlam düğümü olarak bu öğelerle çalışırken yapmalarını istediğimiz şeyi yapmayan sorgular. Neden beklediğinizden farklı davrandıklarını açıklayabilirim. Söz konusu üç hatalı sorgu şunlardır:
//text(): Belgedeki tüm metni döndürür. //a/text(): Belgedeki bağlantıların içindeki tüm metni döndürür. ./a/text(): Sonuç döndürmez.
Bu sonuçların nedeni, bağlamınızın CSS sorgusundan döndürülen bir öğe olmasına rağmen, // tüm belgeye aykırı olmasıdır. Bu XPath'ın gücüdür; CSS bir düğümden yukarıya doğru bir ataya, oradan da o atanın kardeşine gidemez ve aşağıya o kardeşin soyundan gelene doğru yürüyemez. Ancak XPath bunu yapabilir. Bu arada ./, geçerli düğümün alt öğelerini sorgular; burada nokta (.) geçerli düğümü temsil eder ve eğik çizgi (/) bazı alt düğümlere gitmeyi temsil eder - bunun bir nitelik, öğe veya metin olup olmadığı yolun bir sonraki kısmı tarafından belirlenir. Ancak CSS sorgusu tarafından seçilen bir öğenin alt öğesi yoktur, dolayısıyla bu sorgu da hiçbir şey döndürmez. Son demoda üç güzel sorgu var:
.//metin(), ./metin(), normalleştirme-boşluk(./text()).
Normalleştirme alanı sorgusu, XPath işlevinin kullanımını gösterir, ancak aynı zamanda diğer sorgularda bulunan bir sorunu da düzeltir. HTML şu şekilde yapılandırılmıştır:
Selenium WebDriver ile Özellik Testinizi Otomatikleştirme
Sorgu, metin düğümünün başında ve sonunda bir satır beslemesi döndürür.ve normalize-space bunu ortadan kaldırır. Boole değeri dışında bir şeyi XPath girişiyle döndüren herhangi bir XPath işlevinin kullanılması diğer işlevler için de geçerlidir. Aşağıdaki demoda birkaç örnek gösterilmektedir: Bryan Rasmussen tarafından yazılan Pen xpath işlevleri örneklerine [çatallı] bakın. İlk örnek dikkat etmeniz gereken bir sorunu göstermektedir. Özellikle aşağıdaki kod:
document.queryXPaths("substring-after(//a/@href,'https://')");
…bir dize döndürür:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Mantıklı değil mi? Bu işlevler dizileri değil, tek dizeleri veya tek sayıları döndürür. İşlevi birden fazla sonuçla herhangi bir yerde çalıştırmak yalnızca ilk sonucu döndürür. İkinci sonuç gerçekten ne istediğimizi gösteriyor:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Bu, iki dizeden oluşan bir dizi döndürür:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/", "www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath işlevleri, tıpkı JavaScript'teki işlevler gibi iç içe yerleştirilebilir. Dolayısıyla, Smashing Magazine URL yapısını biliyorsak aşağıdakileri yapabiliriz (şablon değişmezlerinin kullanılması önerilir): 'çevir( alt dize( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Bu, ne yaptığını açıklayan yorumlara ihtiyaç duyduğu ölçüde biraz fazla karmaşık hale geliyor: www.smashingmagazine.com/'dan sonra href özelliğinden tüm URL'yi alın, ilk dokuz karakteri kaldırın, sonra da sondaki eğik çizgiden kurtulmak için eğik çizgi (/) karakterini hiçbir şeye çevirin. Ortaya çıkan dizi:
["özellik-test-selenyum-web sürücüsü", "otomatik-test-sonuçları-erişilebilirliği-geliştirme"]
Daha Fazla XPath Kullanım Örnekleri XPath testlerde gerçekten parlayabilir. Bunun nedenini görmek zor değil, çünkü XPath DOM'daki her öğeyi DOM'daki herhangi bir konumdan almak için kullanılabilirken CSS bunu yapamaz. Birçok modern yapı sisteminde CSS sınıflarının tutarlı kalacağına güvenemezsiniz, ancak XPath ile değişen DOM yapısından bağımsız olarak bir öğenin metin içeriğinin ne olduğuna ilişkin daha sağlam eşleşmeler yapabiliyoruz. Dayanıklı XPath testleri yapmanıza olanak tanıyan teknikler üzerine araştırmalar yapılmıştır. Hiçbir şey, bir şeyin yeniden adlandırılması veya kaldırılması nedeniyle bir CSS seçicinin artık çalışmaması nedeniyle testlerin pul pul dökülmesinden ve başarısız olmasından daha kötü olamaz. XPath ayrıca çoklu konum belirleyici çıkarımı konusunda da gerçekten harikadır. Bir öğeyi eşleştirmek için XPath sorgularını kullanmanın birden fazla yolu vardır. Aynı şey CSS'de de geçerli. Ancak XPath sorguları, döndürülenleri sınırlayan, daha hedefli bir şekilde konuları detaylandırabilir ve birkaç olası eşleşmenin olabileceği belirli bir eşleşme bulmanıza olanak tanır. Örneğin, bir kardeş div'i hemen takip eden bir div içinde yer alan belirli bir h2 öğesini döndürmek için XPath'ı kullanabiliriz ve bu div, üzerinde data-testID='leader' özniteliğine sahip bir alt resim öğesi içerir:
bu başlığı anlamayın
Bu başlığı da anlamayın
Lider görselin başlığı
Bu sorgu: document.queryXPaths(' //böl[ aşağıdaki-kardeş::div[1] /img[@data-testID='lider'] ] /h2/ metin() ');
Tüm bunların nasıl bir araya geldiğini görmek için bir demo bırakalım: Bryan Rasmussen tarafından yazılan Kalem Kompleksi H2 Sorgusuna [çatallı] bakın. Yani evet. XPath kullanan bir testte herhangi bir öğeye giden pek çok olası yol vardır. XSLT 1.0'ın Kullanımdan Kaldırılması Chrome ekibinin tarayıcıdan XSLT 1.0 desteğini kaldırmayı planladığını daha önce belirtmiştim. Bu önemlidir çünkü XSLT 1.0, belge dönüşümü için XML odaklı programlamayı kullanır ve bu da çoğu tarayıcıda bulunan XPath 1.0'a dayanır. Bu gerçekleştiğinde XPath'ın önemli bir bileşenini kaybedeceğiz. Ancak XPath'ın test yazmak için gerçekten harika olduğu gerçeği göz önüne alındığında, XPath'ın bir bütün olarak yakın zamanda ortadan kaybolmasının pek olası olmadığını düşünüyorum. Bununla birlikte, insanların bir özellik kaldırıldığında onunla ilgilendiklerini fark ettim. XSLT 1.0'ın kullanımdan kaldırılması durumunda da bu kesinlikle doğrudur. Hacker News'te kullanımdan kaldırmaya karşı argümanlarla dolu bir tartışma sürüyor. Gönderinin kendisi, XSLT ile bir blog çerçevesi oluşturmanın harika bir örneğidir. SenTartışmayı kendiniz okuyabilirsiniz, ancak bu tür durumların üstesinden gelmek için XLST'nin JavaScript'i nasıl kullanabileceğini anlatıyor. Ayrıca tarayıcıların, JavaScript'in Saxon XSLT, XQUERY ve XPath motorlarına bağlantı noktası olan SaxonJS'yi kullanması gerektiğine dair öneriler de gördüm. Bu ilginç bir fikir, özellikle de Saxon-JS'nin bu spesifikasyonların mevcut sürümünü uyguladığı göz önüne alındığında, 1.0'ın ötesinde herhangi bir XPath veya XSLT sürümünü uygulayan ve XQuery'yi uygulayan bir tarayıcı bulunmadığından. SaxonJS'nin ve Saxon motorunun diğer versiyonlarının arkasındaki şirket olan Saxonica'daki Norm Tovey-Walsh'a ulaştım. Dedi ki: "Herhangi bir tarayıcı satıcısı, modern XML teknolojilerini tarayıcıya entegre etmek için SaxonJS'yi başlangıç noktası olarak almakla ilgilenseydi, bunu onlarla tartışmaktan heyecan duyardık."— Norm Tovey-Walsh
Ama şunu da ekledi: "Birisi SaxonJS'yi mevcut haliyle almanın ve tarayıcı yapısına değişmeden bırakmanın ideal yaklaşım olacağını düşünseydi çok şaşırırdım. Bir tarayıcı satıcısı, tarayıcıyı geliştirdikleri gerçeği gereği, entegrasyona bizim 'dışarıdan' yaklaşabileceğimizden çok daha derin bir düzeyde yaklaşabilir."— Norm Tovey-Walsh
Tovey-Walsh'ın yorumlarının XSLT'nin kullanımdan kaldırılması duyurusundan yaklaşık bir hafta önce geldiğini belirtmekte fayda var. Sonuç Devam edebilirim. Ancak umarım bu XPath'ın gücünü göstermiştir ve size onu harika şeyler başarmak için nasıl kullanacağınızı gösteren birçok örnek vermiştir. Varlığını hiç bilmemiş olsanız veya ona ulaşmayı hiç düşünmemiş olsanız bile, tarayıcı yığınındaki eski teknolojinin mükemmel bir örneğidir ve bugün hala pek çok faydası vardır. İleri Okuma
Maroun Ayli, Youssef Bakouny, Nader Jalloul ve Rima Kilany tarafından yazılan "Doğal Dil ile Otomatik Web Testlerinin Dayanıklılığının Artırılması" (ACM Dijital Kütüphanesi) Bu makale, dayanıklılık testleri yazmak için birçok XPath örneği sunmaktadır. XPath (MDN) XPath'ın nasıl çalıştığını ayrıntılarıyla anlatan teknik bir açıklama istiyorsanız burası başlamak için mükemmel bir yerdir. XPath Eğitimi (ZVON)Çok sayıda örnek ve net açıklamalar sayesinde bu eğitimin kendi öğrenimimde en yararlı eğitim olduğunu düşünüyorum. XPatherBu etkileşimli araç doğrudan kodla çalışmanıza olanak tanır.
