მე საკმარისად დიდი ხნის განმავლობაში ვმუშაობდი წინა პლანზე, რათა დავინახო ტენდენცია წლების განმავლობაში: ახალგაზრდა დეველოპერები მუშაობენ პროგრამირების ახალ პარადიგმაზე, მისი ისტორიული კონტექსტის გააზრების გარეშე. რა თქმა უნდა, სავსებით გასაგებია რაღაცის არ ცოდნა. ვებ არის ძალიან დიდი ადგილი უნარებისა და სპეციალობების მრავალფეროვანი ნაკრებით და ჩვენ ყოველთვის არ ვიცით ის, რაც არ ვიცით. ამ სფეროში სწავლა არის უწყვეტი მოგზაურობა და არა ის, რაც ერთხელ ხდება და მთავრდება. მაგალითი: ვიღაცამ ჩემს გუნდში მკითხა, იყო თუ არა შესაძლებელი იმის გაგება, რომ მომხმარებლები შორდებიან UI-ს კონკრეტულ ჩანართს. მე აღვნიშნე JavaScript-ის განტვირთვის ღონისძიება. მაგრამ მათ, ვინც ადრე შეასრულეს ეს, იციან, რომ ეს შესაძლებელია, რადგან მათ მიიღეს გაფრთხილებები სხვა საიტებზე შენახული მონაცემების შესახებ, რისთვისაც ადრე განტვირთვა არის ტიპიური გამოყენების შემთხვევა. მე ასევე მივუთითე გვერდიდამალვა და ხილვადობაChange მოვლენები ჩემს კოლეგას კარგი საზომისთვის. საიდან ვიცოდი ამის შესახებ? იმიტომ, რომ ის სხვა პროექტში გაჩნდა და არა იმიტომ, რომ მასზე ვისწავლე JavaScript-ის თავდაპირველად შესწავლისას. ფაქტია, რომ თანამედროვე ფრონტ-ენდის ჩარჩოები დგას ტექნოლოგიური გიგანტების მხრებზე, რომლებიც მათ წინ უძღოდათ. ისინი ახდენენ განვითარების აბსტრაქტულ პრაქტიკებს, ხშირად დეველოპერის უკეთესი გამოცდილებისთვის, რაც ამცირებს, ან თუნდაც გამორიცხავს, ცოდნის ან შეხების აუცილებლობას, რაც ტრადიციულად აუცილებელი წინაპირობის ცნებები იყო, ალბათ, ყველამ უნდა იცოდეს. განვიხილოთ CSS ობიექტის მოდელი (CSSOM). შეიძლება მოელოდეთ, რომ ნებისმიერს, რომელიც მუშაობს CSS-სა და JavaScript-ში, აქვს CSSOM-ის პრაქტიკული გამოცდილება, მაგრამ ეს ყოველთვის ასე არ იქნება. იყო React პროექტი ელექტრონული კომერციის საიტისთვის, რომელზეც ვმუშაობდი, სადაც გვჭირდებოდა სტილის ცხრილის ჩატვირთვა ამჟამად შერჩეული გადახდის პროვაიდერისთვის. პრობლემა ის იყო, რომ სტილის ცხრილი იტვირთებოდა ყველა გვერდზე, როდესაც ის მხოლოდ კონკრეტულ გვერდზე იყო საჭირო. დეველოპერს, რომელსაც დაევალა ამის გაკეთება, არასოდეს ჩაიტვირთა სტილის ცხრილი დინამიურად. კიდევ ერთხელ, ეს სრულიად გასაგებია, როდესაც React აბსტრაქტებს ტრადიციულ მიდგომას, რომლისკენაც შესაძლოა მიაღწიეთ. CSSOM სავარაუდოდ არ არის ის, რაც გჭირდებათ თქვენს ყოველდღიურ საქმიანობაში. მაგრამ სავარაუდოა, რომ დაგჭირდებათ მასთან ურთიერთობა რაღაც მომენტში, თუნდაც ერთჯერადად. ამ გამოცდილებამ შთამაგონა დამეწერა ეს სტატია. არსებობს მრავალი არსებული ვებ ფუნქციები და ტექნოლოგიები ბუნებრივ გარემოში, რომლებსაც შეიძლება არასოდეს შეეხოთ პირდაპირ თქვენს ყოველდღიურ საქმიანობაში. შესაძლოა, თქვენ საკმაოდ ახალი ხართ ვებ-განვითარებაში და უბრალოდ არ იცით მათი შესახებ, რადგან ჩაძირული ხართ კონკრეტული ჩარჩოს აბსტრაქციაში, რომელიც არ მოითხოვს თქვენგან ღრმად, ან თუნდაც საერთოდ იცოდეთ. მე ვსაუბრობ კონკრეტულად XML-ზე, რომელიც ბევრმა ჩვენგანმა იცის, რომ უძველესი ენაა HTML-ისგან სრულიად განსხვავებული. მე ამას ვახსენებ WHATWG-ის ბოლო დისკუსიების გამო, რომელიც ვარაუდობს, რომ XML დატის მნიშვნელოვანი ნაწილი, რომელიც ცნობილია როგორც XSLT პროგრამირება, უნდა წაიშალოს ბრაუზერებიდან. ეს არის ზუსტად ისეთივე ძველი, არსებული ტექნოლოგია, რომელიც წლების განმავლობაში გვქონდა, რომელიც შეიძლება გამოვიყენოთ ისეთივე პრაქტიკული საქმისთვის, როგორიც იყო ჩემი გუნდის CSSOM სიტუაცია. ადრე გიმუშავიათ XSLT-თან? ვნახოთ, ვეხებით თუ არა ამ ძველ ტექნოლოგიას და გამოვიყენებთ მის მახასიათებლებს XML კონტექსტის მიღმა, რომ გადავჭრათ რეალურ სამყაროში დღეს არსებული პრობლემები. XPath: ცენტრალური API ყველაზე მნიშვნელოვანი XML ტექნოლოგია, რომელიც, ალბათ, ყველაზე გამოსადეგია სწორი XML პერსპექტივის მიღმა, არის XPath, შეკითხვის ენა, რომელიც საშუალებას გაძლევთ იპოვოთ ნებისმიერი კვანძი ან ატრიბუტი მარკირების ხეში ერთი ძირეული ელემენტით. მე მაქვს პირადი მოსიყვარულეობა XSLT-ის მიმართ, მაგრამ ეს ასევე ეყრდნობა XPath-ს და პირადი სიყვარული გვერდიდან უნდა გადავიდეს რეიტინგული მნიშვნელობის მიხედვით. XSLT-ის ამოღების არგუმენტი არ ახსენებს XPath-ს, ასე რომ, ვფიქრობ, ის მაინც დაშვებულია. ეს კარგია, რადგან XPath არის ცენტრალური და ყველაზე მნიშვნელოვანი API ტექნოლოგიების ამ კომპლექტში, განსაკუთრებით მაშინ, როდესაც ცდილობთ იპოვოთ რაიმე გამოსაყენებელი XML-ის ნორმალური გამოყენების მიღმა. ეს მნიშვნელოვანია, რადგან, მიუხედავად იმისა, რომ CSS სელექტორები შეიძლება გამოყენებულ იქნას თქვენი გვერდის ელემენტების უმეტესობის მოსაძებნად, ისინი ვერ პოულობენ მათ ყველა. გარდა ამისა, CSS სელექტორები არ შეიძლება გამოყენებულ იქნას ელემენტის მოსაძებნად DOM-ში მისი ამჟამინდელი პოზიციიდან გამომდინარე. XPath-ს შეუძლია. ახლა, ზოგიერთმა თქვენგანმა, ვინც ამას კითხულობს, შეიძლება იცოდეს XPath, ზოგმა კი არა. XPath არის ტექნოლოგიის საკმაოდ დიდი სფერო და მე ნამდვილად ვერ ვასწავლი ყველა საფუძველს და ასევე გაჩვენებთ საინტერესო საკითხებს ამ ერთ სტატიაში. მე რეალურად ვცადე ამ სტატიის დაწერა, მაგრამ Smashing Magazine-ის საშუალო პუბლიკაცია არ აღემატება 5000 სიტყვას. მე უკვე მეტზე ვიყავი2000 სიტყვა, ხოლო საფუძვლების მხოლოდ ნახევარი. ასე რომ, მე დავიწყებ მაგარი რაღაცეების კეთებას XPath-ით და მოგცემთ რამდენიმე ბმულს, რომელიც შეგიძლიათ გამოიყენოთ საფუძვლებისთვის, თუ თქვენთვის საინტერესოა. XPath-ისა და CSS-ის გაერთიანება XPath-ს შეუძლია ბევრი რამის გაკეთება, რაც CSS სელექტორებს არ შეუძლიათ ელემენტების მოთხოვნისას. მაგრამ CSS სელექტორებს ასევე შეუძლიათ გააკეთონ რამდენიმე რამ, რაც XPath-ს არ შეუძლია, კერძოდ, ელემენტების მოთხოვნა კლასის სახელით.
CSS XPath .myClass /*[შეიცავს(@class, "myClass")]
ამ მაგალითში, CSS კითხულობს ელემენტებს, რომლებიც შეიცავს .myClass კლასის სახელს. იმავდროულად, XPath მაგალითი ითხოვს ელემენტებს, რომლებიც შეიცავს ატრიბუტის კლასს სტრიქონით "myClass". სხვა სიტყვებით რომ ვთქვათ, ის ირჩევს ელემენტებს myClass-ით ნებისმიერ ატრიბუტში, მათ შორის ელემენტებს .myClass კლასის სახელით — ისევე როგორც ელემენტებს სტრიქონში „myClass“, როგორიცაა .myClass2. XPath ამ თვალსაზრისით უფრო ფართოა. ასე რომ, არა. მე არ ვთავაზობ, რომ ჩვენ უნდა გადავაგდოთ CSS და დავიწყოთ ყველა ელემენტის შერჩევა XPath-ის საშუალებით. ეს არ არის აზრი. საქმე იმაშია, რომ XPath-ს შეუძლია გააკეთოს ის, რაც CSS-ს არ შეუძლია და შეიძლება მაინც იყოს ძალიან სასარგებლო, მიუხედავად იმისა, რომ ეს ძველი ტექნოლოგიაა ბრაუზერის დასტაში და შეიძლება ერთი შეხედვით აშკარად არ ჩანდეს. მოდით გამოვიყენოთ ეს ორი ტექნოლოგია ერთად არა მხოლოდ იმიტომ, რომ ჩვენ შეგვიძლია, არამედ იმიტომ, რომ ჩვენ ვისწავლით რაღაცას XPath-ის შესახებ ამ პროცესში, რაც მას კიდევ ერთ ხელსაწყოს გავხდით თქვენს დასტაში – ის, ვინც შესაძლოა არ იცოდით, იყო იქ! პრობლემა ის არის, რომ JavaScript-ის document.evaluate მეთოდი და შეკითხვის ამორჩევის სხვადასხვა მეთოდები, რომლებსაც ვიყენებთ JavaScript-ისთვის CSS API-ებთან შეუთავსებელია. მე შევქმენი თავსებადი შეკითხვის API, რომ დაგვეწყო, თუმცა, რა თქმა უნდა, ამაზე ბევრი არ მიფიქრია, რადგან ეს არის გადახვევა იმისგან, რასაც ჩვენ ვაკეთებთ. აქ არის საკმაოდ მარტივი სამუშაო მაგალითი მრავალჯერადი შეკითხვის კონსტრუქტორის: იხილეთ Pen queryXPath [ჩანგალი] ბრაიან რასმუსენის მიერ. მე დავამატე ორი მეთოდი დოკუმენტის ობიექტზე: queryCSSSelectors (რომელიც არსებითად არის querySelectorAll) და queryXPaths. ორივე აბრუნებს queryResults ობიექტს:
{ queryType: nodes | სიმებიანი | ნომერი | ლოგიკური, შედეგები: ნებისმიერი[] // html ელემენტები, xml ელემენტები, სტრიქონები, რიცხვები, ლოგიკები, queryCSSS სელექტორები: (შეკითხვა: string, შესწორება: ლოგიკური) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }
queryCSSSelectors და queryXpaths ფუნქციები აწარმოებენ შეკითხვას, რომელსაც თქვენ აძლევთ მათ შედეგების მასივის ელემენტებზე, თუ რა თქმა უნდა, შედეგების მასივი არის კვანძების ტიპის. წინააღმდეგ შემთხვევაში, ის დააბრუნებს queryResult-ს ცარიელი მასივით და კვანძების ტიპით. თუ amend თვისება დაყენებულია true-ზე, ფუნქციები შეცვლიან საკუთარ შეკითხვის შედეგებს. არავითარ შემთხვევაში არ უნდა იქნას გამოყენებული საწარმოო გარემოში. მე ამას ვაკეთებ ამ გზით მხოლოდ ორი შეკითხვის API-ის ერთად გამოყენების სხვადასხვა ეფექტის დემონსტრირებისთვის. კითხვების მაგალითები მე მსურს ვაჩვენო XPath-ის სხვადასხვა მოთხოვნების რამდენიმე მაგალითი, რომლებიც აჩვენებენ ზოგიერთ მძლავრ რამეს, რაც მათ შეუძლიათ და როგორ შეიძლება მათი გამოყენება სხვა მიდგომების ნაცვლად. პირველი მაგალითია //li/text(). ეს ითხოვს ყველა li ელემენტს და აბრუნებს მათ ტექსტურ კვანძებს. ასე რომ, თუ ჩვენ ვკითხულობთ შემდეგ HTML-ს:
- ერთი
- ორი
- სამი
…ეს არის ის, რაც დაბრუნდა:
{"queryType":"xpathEvaluate", "results":["ერთი", "ორი", "სამი"],"resultType":"სტრიქონი"}
სხვა სიტყვებით რომ ვთქვათ, მივიღებთ შემდეგ მასივს: ["ერთი", "ორი", "სამი"]. ჩვეულებრივ, თქვენ უნდა მოითხოვოთ li ელემენტების მიღება, რომ მიიღოთ ეს, გადააქციოთ ამ მოთხოვნის შედეგი მასივად, დაასახელოთ მასივი და დააბრუნოთ თითოეული ელემენტის ტექსტური კვანძი. მაგრამ ჩვენ შეგვიძლია ამის გაკეთება უფრო მოკლედ XPath-ით: document.queryXPaths("//li/text()"). შედეგები.
გაითვალისწინეთ, რომ ტექსტური კვანძის მიღების გზა არის ტექსტის () გამოყენება, რომელიც ჰგავს ფუნქციის ხელმოწერას — და ასეც არის. ის აბრუნებს ელემენტის ტექსტურ კვანძს. ჩვენს მაგალითში არის სამი li ელემენტი მარკირებაში, თითოეული შეიცავს ტექსტს ("ერთი", "ორი" და "სამი").
მოდით შევხედოთ ტექსტის () მოთხოვნის კიდევ ერთ მაგალითს. დავუშვათ, რომ ეს არის ჩვენი მარკირება:
მოდით დავწეროთ მოთხოვნა, რომელიც დააბრუნებს href ატრიბუტის მნიშვნელობას: document.queryXPaths("//a[text() = 'შესვლა']/@href"). შედეგები.
ეს არის XPath მოთხოვნა მიმდინარე დოკუმენტზე, ისევე როგორც ბოლო მაგალითი, მაგრამ ამჯერად ჩვენ ვაბრუნებთ ბმულის href ატრიბუტს (ელემენტი), რომელიც შეიცავს ტექსტს „შესვლა“. ფაქტობრივი დაბრუნდაშედეგი არის ["/login.html"]. XPath ფუნქციების მიმოხილვა არსებობს XPath-ის მრავალი ფუნქცია და თქვენ ალბათ არ იცნობთ მათ. არსებობს რამდენიმე, ვფიქრობ, რომ ღირს იცოდეთ, მათ შორის შემდეგი:
starts-withIf ტექსტი იწყება კონკრეტული სხვა ტექსტის მაგალითით, starts-with(@href, 'http:') აბრუნებს true, თუ href ატრიბუტი იწყება http:-ით. შეიცავს თუ ტექსტი შეიცავს კონკრეტულ სხვა ტექსტის მაგალითს, contain(text(), "Smashing Magazine") აბრუნებს true, თუ ტექსტის კვანძი შეიცავს სიტყვებს "Smashing Magazine" მასში სადმე. count აბრუნებს რაოდენობას რამდენი შესატყვისია მოთხოვნაზე. მაგალითად, count(//*[starts-with(@href, 'http:']) აბრუნებს რაოდენობას, თუ რამდენ ბმულს აქვს კონტექსტური კვანძის ელემენტები href ატრიბუტით, რომელიც შეიცავს http:-ით დაწყებულ ტექსტს. substring მუშაობს JavaScript ქვესტრინგის მსგავსად, გარდა იმისა, რომ სტრიქონს არგუმენტად გადასცემთ. მაგალითად, substring ("ჩემი ტექსტი", 2, 4) აბრუნებს "y t". substring-before აბრუნებს სტრიქონის ნაწილს სხვა სტრიქონის წინ. მაგალითად, substing-before("ჩემი ტექსტი", " ") აბრუნებს "ჩემს". ანალოგიურად, substring-before("hi","bye") აბრუნებს ცარიელ სტრიქონს. substring-after აბრუნებს სტრიქონის ნაწილს მეორე სტრიქონის შემდეგ. მაგალითად, substing-after("ჩემი ტექსტი", "") აბრუნებს "ტექსტს". ანალოგიურად, substring-after("hi","bye") აბრუნებს ცარიელ სტრიქონს. normalize-space აბრუნებს არგუმენტის სტრიქონს უფსკრულით, რომელიც ნორმალიზდება წინა და უკანა სივრცის ამოღებით და უფსკრული სიმბოლოების თანმიმდევრობების ერთი ინტერვალით ჩანაცვლებით. not აბრუნებს ლოგიკურ ნამდვილს, თუ არგუმენტი მცდარია, წინააღმდეგ შემთხვევაში მცდარია. true აბრუნებს ლოგიკურს true. false აბრუნებს ლოგიკურ false-ს. concat იგივეა, რაც JavaScript concat, გარდა იმისა, რომ არ აწარმოებთ მას, როგორც მეთოდს სტრიქონზე. ამის ნაცვლად, თქვენ აყენებთ ყველა სტრიქონს, რომლის შეერთებაც გსურთ. string-lengthეს არ არის იგივე, რაც JavaScript-ის სიმის სიგრძე, არამედ აბრუნებს არგუმენტად მოცემული სტრიქონის სიგრძეს. translateThis იღებს სტრიქონს და ცვლის მეორე არგუმენტს მესამე არგუმენტით. მაგალითად, translate ("abcdef", "abc", "XYZ") გამოაქვს XYZdef.
გარდა ამ კონკრეტული XPath ფუნქციებისა, არის რიგი სხვა ფუნქციები, რომლებიც მუშაობს ისევე, როგორც მათი JavaScript ანალოგები - ან ანალოგები ძირითადად პროგრამირების ნებისმიერ ენაზე - და რომლებიც ალბათ ასევე გამოგადგებათ, როგორიცაა იატაკი, ჭერი, მრგვალი, ჯამი და ა.შ. შემდეგი დემო ჩვენება ასახავს თითოეულ ამ ფუნქციას: იხილეთ კალამი XPath რიცხვითი ფუნქციები [ჩანგალი] ბრაიან რასმუსენის მიერ. გაითვალისწინეთ, რომ, ისევე როგორც სტრიქონების მანიპულირების ფუნქციების უმეტესობა, ბევრი რიცხვითი ფუნქციები იღებს ერთ შეყვანას. ეს, რა თქმა უნდა, იმიტომ ხდება, რომ ისინი უნდა იქნას გამოყენებული შეკითხვისთვის, როგორც ბოლო XPath მაგალითში: //li[floor(text()) > 250]/@val
თუ იყენებთ მათ, როგორც ამას მაგალითების უმეტესობა აკეთებს, თქვენ დაასრულებთ მის გაშვებას პირველ კვანძზე, რომელიც ემთხვევა გზას. ასევე არის გარკვეული ტიპის კონვერტაციის ფუნქციები, რომლებსაც ალბათ უნდა მოერიდოთ, რადგან JavaScript-ს უკვე აქვს საკუთარი ტიპის კონვერტაციის პრობლემები. მაგრამ შეიძლება იყოს შემთხვევები, როდესაც გსურთ სტრიქონის გადაქცევა რიცხვად, რათა შეამოწმოთ იგი სხვა რიცხვთან. ფუნქციები, რომლებიც ადგენენ რაღაცის ტიპს, არის ლოგიკური, რიცხვი, სტრიქონი და კვანძი. ეს არის XPath მონაცემთა მნიშვნელოვანი ტიპები. და როგორც თქვენ წარმოიდგინეთ, ამ ფუნქციების უმეტესობა შეიძლება გამოყენებულ იქნას მონაცემთა ტიპებზე, რომლებიც არ არის DOM კვანძები. მაგალითად, substring-after იღებს სტრიქონს, როგორც უკვე დავწერეთ, მაგრამ ეს შეიძლება იყოს სტრიქონი href ატრიბუტიდან. ის ასევე შეიძლება იყოს მხოლოდ სტრიქონი:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
ცხადია, ეს მაგალითი დაგვიბრუნებს შედეგების მასივს, როგორც ["მსოფლიო"]. ამის საჩვენებლად, მე შევქმენი დემო გვერდი ფუნქციების გამოყენებით, რაც არ არის DOM კვანძები: იხილეთ Pen queryXPath [ჩანგალი] ბრაიან რასმუსენის მიერ. თქვენ უნდა გაითვალისწინოთ translate ფუნქციის გასაკვირი ასპექტი, რომელიც არის ის, რომ თუ თქვენ გაქვთ სიმბოლო მეორე არგუმენტში (ანუ, სიმბოლოების სია, რომელთა თარგმნა გსურთ) და არ არის შესატყვისი სიმბოლო, რომლითაც უნდა ითარგმნოთ, ეს სიმბოლო წაიშლება გამოსავალიდან. ამრიგად, ეს:
translate('გამარჯობა, მე მქვია ინიგო მონტოია, შენ მოკალი მამაჩემი, მოემზადე სიკვდილისთვის','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… შედეგები სტრიქონში, მათ შორის სივრცეები: ["***"]
ეს ნიშნავს, რომ ასო "a" ითარგმნება ვარსკვლავით (*), მაგრამ ყველა სხვა სიმბოლო, რომელსაც არ აქვს თარგმანი, მოცემული სამიზნე სტრიქონით, მთლიანად ამოღებულია. უფსკრული არის ის, რაც დაგვრჩათარგმნილ "a" სიმბოლოებს შორის. შემდეგ ისევ ეს შეკითხვა:
translate('გამარჯობა, მე მქვია ინიგო მონტოია, შენ მოკალი მამაჩემი, მოემზადე სიკვდილისთვის','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','***************************************************')")
... არ აქვს პრობლემა და გამოაქვს შედეგი, რომელიც ასე გამოიყურება:
"***** ** **** ** ***** ******* *** ***** ** ***** ***** ** ***"
შეიძლება გაგიკვირდეთ, რომ JavaScript-ში არ არსებობს იოლი გზა იმის გასაკეთებლად, რასაც აკეთებს XPath translate ფუნქცია, თუმცა მრავალი გამოყენების შემთხვევაში, ReplaceAll რეგულარული გამონათქვამებით შეიძლება გაუმკლავდეს მას. თქვენ შეგიძლიათ გამოიყენოთ იგივე მიდგომა, რაც მე ვაჩვენე, მაგრამ ეს არაოპტიმალურია, თუ მხოლოდ სტრიქონების თარგმნა გსურთ. შემდეგი დემო ვერსია აფუჭებს XPath-ის თარგმნის ფუნქციას JavaScript-ის ვერსიის უზრუნველსაყოფად: იხილეთ კალმის თარგმნის ფუნქცია [ჩანგალი] ბრაიან რასმუსენის მიერ. სად შეიძლება გამოიყენო მსგავსი რამ? განვიხილოთ Caesar Cipher-ის დაშიფვრა სამ ადგილიანი ოფსეტურით (მაგ., უმაღლესი დონის დაშიფვრა ძვ.წ. 48 წლიდან):
translate ("კეისარი აპირებს რუბიკონის გადალახვას!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
შეყვანილი ტექსტი "კეისარი გეგმავს რუბიკონის გადალახვას!" შედეგები "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" განსხვავებული შესაძლებლობების კიდევ ერთი სწრაფი მაგალითის მოსაყვანად, მე შევქმენი ლითონის ფუნქცია, რომელიც იღებს სტრიქონის შეყვანას და იყენებს translate ფუნქციას ტექსტის დასაბრუნებლად, მათ შორის ყველა სიმბოლოს, რომელიც იღებს umlauts-ს. იხილეთ კალმის ლითონის ფუნქცია [ჩანგალი] ბრაიან რასმუსენის მიერ.
const metal = (str) => { დაბრუნება translate (str, "AOUaou", "ÄÖÜäöü"); }
და თუ მოგეცემათ ტექსტი „Motley Crue rules, rock on dudes!“, აბრუნებს „Mötley Crüe rüles, röck ön düdes!“ ცხადია, ამ ფუნქციის ყველანაირი პაროდიული გამოყენება შეიძლება. თუ ეს თქვენ ხართ, მაშინ ეს TVTropes სტატია უნდა მოგაწოდოთ უამრავი შთაგონება. CSS-ის გამოყენება XPath-ით დაიმახსოვრე ჩვენი მთავარი მიზეზი CSS სელექტორების XPath-თან ერთად გამოყენებისთვის: CSS-ს საკმაოდ კარგად ესმის, რა არის კლასი, მაშინ როცა XPath-ის საუკეთესო საშუალებაა კლასის ატრიბუტის სტრიქონების შედარება. ეს იმუშავებს უმეტეს შემთხვევაში. მაგრამ თუ ოდესმე შეხვდებით სიტუაციას, როდესაც, ვთქვათ, ვინმემ შექმნა კლასები სახელად .primaryLinks და .primaryLinks2 და თქვენ იყენებდით XPath-ს .primaryLinks კლასის მისაღებად, მაშინ სავარაუდოდ პრობლემები შეგექმნებათ. სანამ მსგავსი სულელური არაფერია, თქვენ ალბათ გამოიყენებდით XPath-ს. მაგრამ სამწუხაროა იმის თქმა, რომ მე ვმუშაობდი ისეთ ადგილებში, სადაც ადამიანები ასეთ სისულელეებს აკეთებენ. აქ არის კიდევ ერთი დემო ვერსია CSS-ისა და XPath-ის გამოყენებით. ის გვიჩვენებს რა ხდება, როდესაც ჩვენ ვიყენებთ კოდს XPath-ის გასაშვებად კონტექსტურ კვანძზე, რომელიც არ არის დოკუმენტის კვანძი. იხილეთ კალამი css და xpath ერთად [გატეხილი] ბრაიან რასმუსენის მიერ. CSS მოთხოვნა არის .relatedarticles a, რომელიც იღებს ორ a ელემენტს div-ში, რომელსაც ენიჭება .relatedarticles კლასში. ამის შემდეგ არის სამი „ცუდი“ მოთხოვნა, ანუ მოთხოვნები, რომლებიც არ აკეთებენ იმას, რაც ჩვენ გვინდა, რომ გააკეთონ ამ ელემენტების, როგორც კონტექსტური კვანძის გამოყენებისას. მე შემიძლია აგიხსნათ, რატომ იქცევიან ისინი განსხვავებულად, ვიდრე თქვენ მოელოდით. სამი ცუდი შეკითხვაა:
//text(): აბრუნებს დოკუმენტში არსებულ მთელ ტექსტს. //a/text(): აბრუნებს დოკუმენტის ბმულების შიგნით არსებულ მთელ ტექსტს. ./a/text(): არ აბრუნებს შედეგს.
ამ შედეგების მიზეზი არის ის, რომ სანამ თქვენი კონტექსტი არის CSS მოთხოვნიდან დაბრუნებული ელემენტები, // ეწინააღმდეგება მთელ დოკუმენტს. ეს არის XPath-ის სიძლიერე; CSS არ შეიძლება გადავიდეს კვანძიდან წინაპარზე, შემდეგ კი ამ წინაპრის და-ძმაზე და დაბლა გადავიდეს ამ ძმის შთამომავლამდე. მაგრამ XPath-ს შეუძლია. იმავდროულად, ./ კითხულობს მიმდინარე კვანძის შვილებს, სადაც წერტილი (.) წარმოადგენს მიმდინარე კვანძს, ხოლო წინ ხაზები (/) წარმოადგენს რომელიმე შვილობილ კვანძში გადასვლას - იქნება ეს ატრიბუტი, ელემენტი თუ ტექსტი, განისაზღვრება ბილიკის შემდეგი ნაწილით. მაგრამ არ არის CSS მოთხოვნის მიერ არჩეული ელემენტი, ამდენად, ეს შეკითხვა ასევე არაფერს აბრუნებს. ბოლო დემოში არის სამი კარგი შეკითხვა:
.//text(), ./text(), normalize-space(./text()).
ნორმალიზებული სივრცის მოთხოვნა აჩვენებს XPath ფუნქციის გამოყენებას, მაგრამ ასევე აფიქსირებს პრობლემას, რომელიც შედის სხვა შეკითხვებში. HTML სტრუქტურირებულია ასე:
თქვენი ფუნქციების ტესტირების ავტომატიზაცია Selenium WebDriver-ით
შეკითხვა აბრუნებს ხაზს ტექსტის კვანძის დასაწყისში და ბოლოს,და normalize-space ხსნის ამას. ნებისმიერი XPath ფუნქციის გამოყენება, რომელიც აბრუნებს რაღაც სხვას, გარდა ლოგიკური შეყვანით XPath, ვრცელდება სხვა ფუნქციებზე. შემდეგი დემო გვიჩვენებს რამდენიმე მაგალითს: იხილეთ Pen xpath ფუნქციების მაგალითები [ჩანგალი] ბრაიან რასმუსენის მიერ. პირველი მაგალითი გვიჩვენებს პრობლემას, რომელსაც ყურადღება უნდა მიაქციოთ. კერძოდ, შემდეგი კოდი:
document.queryXPaths("substring-after(//a/@href,'https://')");
…აბრუნებს ერთ სტრიქონს:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
აზრი აქვს, არა? ეს ფუნქციები არ აბრუნებს მასივებს, არამედ ერთ სტრიქონებს ან ცალკეულ რიცხვებს. ფუნქციის ნებისმიერ ადგილას გაშვება მრავალი შედეგით მხოლოდ პირველ შედეგს აბრუნებს. მეორე შედეგი გვიჩვენებს, რა გვინდა სინამდვილეში:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
რომელიც აბრუნებს ორი სტრიქონის მასივს:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath ფუნქციები შეიძლება იყოს ჩადებული ისევე, როგორც ფუნქციები JavaScript-ში. ასე რომ, თუ ვიცით Smashing Magazine URL-ის სტრუქტურა, შეგვიძლია გავაკეთოთ შემდეგი (რეკომენდებულია შაბლონის ლიტერალების გამოყენება): `თარგმნა( ქვესტრიქონი ( substring-after (./@href, 'www.smashingmagazine.com/') ,9), ''/'','')''
ეს ძალიან რთული ხდება იმდენად, რამდენადაც მას სჭირდება კომენტარები, სადაც აღწერილია რას აკეთებს: აიღეთ მთელი URL ატრიბუტი href ატრიბუტიდან www.smashingmagazine.com/-ის შემდეგ, წაშალეთ პირველი ცხრა სიმბოლო, შემდეგ გადათარგმნეთ წინ დახრილი (/) სიმბოლო არაფრად, რათა თავიდან აიცილოთ დასრულებული წინ დახრილი. შედეგად მიღებული მასივი:
["feature-testing-selenium-webdriver", "automated-test-results-improve-accessibility"]
მეტი XPath გამოყენების შემთხვევები XPath-ს ნამდვილად შეუძლია გაბრწყინდეს ტესტირებაში. მიზეზის დანახვა ძნელი არ არის, რადგან XPath შეიძლება გამოყენებულ იქნას DOM-ში ყველა ელემენტის მისაღებად, DOM-ის ნებისმიერი პოზიციიდან, ხოლო CSS – არა. თქვენ არ შეგიძლიათ გქონდეთ იმის იმედი, რომ CSS კლასები დარჩება თანმიმდევრული მრავალ თანამედროვე build სისტემაში, მაგრამ XPath-ით ჩვენ შეგვიძლია უფრო მძლავრი შეხამება, თუ რა არის ელემენტის ტექსტის შინაარსი, მიუხედავად იმისა, რომ იცვლება DOM სტრუქტურა. ჩატარდა კვლევა ტექნიკის შესახებ, რომელიც საშუალებას გაძლევთ გააკეთოთ ელასტიური XPath ტესტები. არაფერია იმაზე უარესი, ვიდრე ტესტების გაშლა და წარუმატებლობა მხოლოდ იმიტომ, რომ CSS ამომრჩეველი აღარ მუშაობს, რადგან რაღაც გადაერქვა ან წაიშალა. XPath ასევე შესანიშნავია მრავალი ლოკატორის მოპოვებაში. არსებობს ერთზე მეტი გზა, რომ გამოიყენოთ XPath მოთხოვნები ელემენტის შესატყვისად. იგივე ეხება CSS-ს. მაგრამ XPath-ის მოთხოვნებს შეუძლიათ უფრო მიზანმიმართული გზით შეამჩნიონ საგნები, რაც ზღუდავს დაბრუნებულს, რაც საშუალებას მოგცემთ იპოვოთ კონკრეტული შესატყვისი, სადაც შეიძლება იყოს რამდენიმე შესაძლო შესატყვისი. მაგალითად, ჩვენ შეგვიძლია გამოვიყენოთ XPath კონკრეტული h2 ელემენტის დასაბრუნებლად, რომელიც შეიცავს div-ში, რომელიც დაუყოვნებლივ მიჰყვება ძმურ div-ს, რომელიც, თავის მხრივ, შეიცავს ბავშვის გამოსახულების ელემენტს data-testID = "ლიდერი" ატრიბუტით:
არ მიიღოთ ეს სათაური
არ მიიღოთ ეს სათაურიც
ლიდერის გამოსახულების სათაური
ეს არის შეკითხვა: document.queryXPaths(` //div[ შემდეგი-ძმა::div[1] /img[@data-testID='ლიდერი'] ] /სთ2/ ტექსტი () `);
მოდით ჩავაგდოთ დემო ვერსია, რომ ვნახოთ, როგორ ხდება ეს ყველაფერი ერთად: იხილეთ Pen Complex H2 Query [გატეხილი] ბრაიან რასმუსენის მიერ. ასე რომ, დიახ. ტესტში ნებისმიერი ელემენტისკენ მიმავალი მრავალი შესაძლო გზა არსებობს XPath-ის გამოყენებით. XSLT 1.0 გაუქმება ადრე აღვნიშნე, რომ Chrome-ის გუნდი გეგმავს ბრაუზერიდან XSLT 1.0 მხარდაჭერის ამოღებას. ეს მნიშვნელოვანია, რადგან XSLT 1.0 იყენებს XML-ზე ორიენტირებულ პროგრამირებას დოკუმენტის ტრანსფორმაციისთვის, რომელიც, თავის მხრივ, ეყრდნობა XPath 1.0-ს, რაც გვხვდება უმეტეს ბრაუზერებში. როდესაც ეს მოხდება, ჩვენ დავკარგავთ XPath-ის ძირითად კომპონენტს. მაგრამ იმის გათვალისწინებით, რომ XPath მართლაც შესანიშნავია ტესტების დასაწერად, ნაკლებად სავარაუდოა, რომ XPath მთლიანად გაქრება მალე. როგორც ვთქვი, მე შევამჩნიე, რომ ხალხი დაინტერესებულია ფუნქციით, როდესაც ის წაიშლება. და ეს ნამდვილად მართალია XSLT 1.0-ის მოძველების შემთხვევაში. მთელი დისკუსია მიმდინარეობს Hacker News-ში, რომელიც სავსეა გაუქმების წინააღმდეგ არგუმენტებით. პოსტი თავისთავად არის XSLT-ით ბლოგის ჩარჩოს შექმნის შესანიშნავი მაგალითი. შენშეგიძლიათ თავად წაიკითხოთ დისკუსია, მაგრამ ის ასახავს იმას, თუ როგორ შეიძლება JavaScript-ის გამოყენება XLST-ისთვის ამ სახის შემთხვევების მოსაგვარებლად. მე ასევე მინახავს წინადადებები, რომ ბრაუზერებმა უნდა გამოიყენონ SaxonJS, რომელიც არის JavaScript-ის Saxon XSLT, XQUERY და XPath ძრავების პორტი. ეს საინტერესო იდეაა, განსაკუთრებით იმის გამო, რომ Saxon-JS ახორციელებს ამ სპეციფიკაციების მიმდინარე ვერსიას, მაშინ როდესაც არ არსებობს ბრაუზერი, რომელიც ახორციელებს XPath-ის ან XSLT-ის რომელიმე ვერსიას 1.0-ის მიღმა და არცერთი, რომელიც ახორციელებს XQuery-ს. მე მივმართე Norm Tovey-Walsh-ს Saxonica-ში, კომპანია SaxonJS-ის და Saxon ძრავის სხვა ვერსიების უკან. მან თქვა: „თუ რომელიმე ბრაუზერის გამყიდველს აინტერესებდა SaxonJS, როგორც ამოსავალი წერტილი ბრაუზერში თანამედროვე XML ტექნოლოგიების ინტეგრირებისთვის, ჩვენ აღფრთოვანებული ვიქნებით მათთან განხილვით.“ - Norm Tovey-Walsh.
მაგრამ ასევე დაამატა: "ძალიან გამიკვირდება, თუ ვინმე იფიქრებს, რომ SaxonJS-ის ამჟამინდელი სახით მიღება და ბრაუზერში უცვლელად ჩაშვება იქნება იდეალური მიდგომა. ბრაუზერის გამყიდველს, ბრაუზერის აშენების ბუნებიდან გამომდინარე, შეუძლია ინტეგრაციას მიუახლოვდეს ბევრად უფრო ღრმა დონეზე, ვიდრე ჩვენ შეგვიძლია "გარედან"" - Norm Tovey-Walsh.
აღსანიშნავია, რომ Tovey-Walsh-ის კომენტარები მოვიდა XSLT გაუქმების შესახებ განცხადებამდე დაახლოებით ერთი კვირით ადრე. დასკვნა მე შემეძლო გამეგრძელებინა. მაგრამ ვიმედოვნებ, რომ ამან აჩვენა XPath-ის ძალა და მოგცეთ უამრავი მაგალითი, რომელიც აჩვენებს, თუ როგორ გამოიყენოთ იგი დიდი მიზნების მისაღწევად. ეს არის ძველი ტექნოლოგიის შესანიშნავი მაგალითი ბრაუზერის დასტაში, რომელსაც დღესაც აქვს უამრავი სარგებლობა, მაშინაც კი, თუ არასოდეს იცოდით მისი არსებობის შესახებ ან არასოდეს გიფიქრიათ მის მიღწევაზე. შემდგომი კითხვა
„ავტომატური ვებ ტესტების გამძლეობის გაძლიერება ბუნებრივი ენით“ (ACM ციფრული ბიბლიოთეკა) მარუნ აილის, იუსეფ ბაკუნის, ნადერ ჯალოულისა და რიმა კილანის მიერ. XPath (MDN) ეს შესანიშნავი ადგილია დასაწყებად, თუ გსურთ ტექნიკური ახსნა, თუ როგორ მუშაობს XPath. XPath Tutorial (ZVON) მე მივიჩნიე, რომ ეს სახელმძღვანელო ყველაზე სასარგებლოა ჩემს სწავლაში, უამრავი მაგალითისა და მკაფიო განმარტებების წყალობით. XPatherეს ინტერაქტიული ინსტრუმენტი საშუალებას გაძლევთ უშუალოდ იმუშაოთ კოდთან.
