ខ្ញុំបានស្ថិតនៅក្នុងការអភិវឌ្ឍន៍ផ្នែកខាងមុខយូរល្មមដើម្បីមើលឃើញនិន្នាការមួយក្នុងប៉ុន្មានឆ្នាំមកនេះ៖ អ្នកអភិវឌ្ឍន៍វ័យក្មេងធ្វើការជាមួយគំរូថ្មីនៃការសរសេរកម្មវិធីដោយមិនយល់ពីបរិបទប្រវត្តិសាស្ត្ររបស់វា។ ជាការពិតណាស់ វាពិតជាអាចយល់បានយ៉ាងល្អឥតខ្ចោះ ក្នុងការមិនស្គាល់អ្វីមួយ។ គេហទំព័រគឺជាកន្លែងដ៏ធំដែលមានជំនាញ និងជំនាញផ្សេងៗគ្នា ហើយយើងមិនតែងតែដឹងពីអ្វីដែលយើងមិនដឹងនោះទេ។ ការរៀនសូត្រក្នុងវិស័យនេះគឺជាដំណើរបន្តជាជាងអ្វីដែលកើតឡើងម្តងហើយចប់។ ករណីនៅក្នុងចំណុច៖ នរណាម្នាក់នៅក្នុងក្រុមរបស់ខ្ញុំបានសួរថាតើវាអាចទៅរួចទេក្នុងការប្រាប់ថាតើអ្នកប្រើប្រាស់រុករកឆ្ងាយពីផ្ទាំងជាក់លាក់ណាមួយនៅក្នុង UI ដែរឬទេ។ ខ្ញុំបានចង្អុលបង្ហាញព្រឹត្តិការណ៍មុនពេលមិនបានផ្ទុករបស់ JavaScript។ ប៉ុន្តែអ្នកដែលបានដោះស្រាយបញ្ហានេះពីមុនដឹងថាវាអាចទៅរួច ពីព្រោះពួកគេបានទទួលការជូនដំណឹងអំពីទិន្នន័យដែលមិនបានរក្សាទុកនៅលើគេហទំព័រផ្សេងទៀត ដែលមុនពេល unload គឺជាករណីប្រើប្រាស់ធម្មតា។ ខ្ញុំក៏បានចង្អុលបង្ហាញ pageHide and visibilityChange events ដល់សហសេវិករបស់ខ្ញុំសម្រាប់វិធានការល្អ។ តើខ្ញុំដឹងដោយរបៀបណា? ដោយសារតែវាកើតឡើងនៅក្នុងគម្រោងមួយផ្សេងទៀត មិនមែនដោយសារតែខ្ញុំបានសិក្សាវានៅពេលដំបូងរៀន JavaScript នោះទេ។ ការពិតគឺថាស៊ុមខាងមុខទំនើបកំពុងឈរនៅលើស្មានៃក្រុមហ៊ុនបច្ចេកវិទ្យាយក្សដែលនាំមុខពួកគេ។ ពួកគេអនុវត្តការអភិវឌ្ឍន៍អរូបី ជាញឹកញាប់សម្រាប់បទពិសោធន៍អ្នកអភិវឌ្ឍន៍កាន់តែប្រសើរ ដែលកាត់បន្ថយ ឬសូម្បីតែលុបបំបាត់ តម្រូវការដើម្បីដឹង ឬប៉ះអ្វីដែលជាប្រពៃណីជាគោលគំនិតសំខាន់ៗដែលគ្រប់គ្នាប្រហែលជាគួរដឹង។ ពិចារណាគំរូវត្ថុ CSS (CSSOM) ។ អ្នកអាចរំពឹងថាអ្នកណាម្នាក់ដែលធ្វើការនៅក្នុង CSS និង JavaScript មានបទពិសោធន៍ CSSOM ជាច្រើននៅលើដៃ ប៉ុន្តែវាមិនតែងតែជាករណីនោះទេ។ មានគម្រោង React សម្រាប់គេហទំព័រពាណិជ្ជកម្មអេឡិចត្រូនិចដែលខ្ញុំបានធ្វើការនៅកន្លែងដែលយើងត្រូវការដើម្បីផ្ទុកសន្លឹករចនាប័ទ្មសម្រាប់អ្នកផ្តល់ការទូទាត់ដែលបានជ្រើសរើសបច្ចុប្បន្ន។ បញ្ហាគឺថាសន្លឹករចនាប័ទ្មកំពុងផ្ទុកនៅគ្រប់ទំព័រ នៅពេលដែលវាត្រូវការតែនៅលើទំព័រជាក់លាក់ប៉ុណ្ណោះ។ អ្នកអភិវឌ្ឍន៍ដែលមានភារកិច្ចធ្វើឱ្យវាកើតឡើងមិនដែលបានផ្ទុកសន្លឹករចនាប័ទ្មថាមវន្តទេ។ ជាថ្មីម្តងទៀត នេះគឺអាចយល់បានទាំងស្រុង នៅពេលដែល React abstracts ចេញឆ្ងាយពីវិធីសាស្រ្តប្រពៃណីដែលអ្នកប្រហែលជាបានឈានដល់។ 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 ជាមធ្យមមិនមានលើសពី 5,000 ពាក្យទេ។ ខ្ញុំមានអាយុច្រើនជាងហើយ។2,000 ពាក្យខណៈពេលដែលមានតែពាក់កណ្តាលនៃមូលដ្ឋាន។ ដូច្នេះ ខ្ញុំនឹងចាប់ផ្តើមធ្វើរឿងល្អៗជាមួយ 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 មិនអាច ហើយនៅតែអាចមានប្រយោជន៍ខ្លាំង ទោះបីជាវាជាបច្ចេកវិទ្យាចាស់នៅក្នុងបណ្តុំកម្មវិធីរុករក ហើយប្រហែលជាមិនច្បាស់នៅ glance ដំបូងក៏ដោយ។ ចូរយើងប្រើបច្ចេកវិទ្យាទាំងពីរជាមួយគ្នា មិនត្រឹមតែដោយសារតែយើងអាចប៉ុណ្ណោះទេ ប៉ុន្តែដោយសារតែយើងនឹងរៀនអ្វីមួយអំពី XPath នៅក្នុងដំណើរការនេះ ធ្វើឱ្យវាក្លាយជាឧបករណ៍មួយផ្សេងទៀតនៅក្នុងជង់របស់អ្នក — មួយដែលអ្នកប្រហែលជាមិនធ្លាប់បានដឹងពីមុនមក! បញ្ហាគឺថាវិធីសាស្ត្រ document.evaluate របស់ JavaScript និងវិធីសាស្ត្រជ្រើសរើសសំណួរផ្សេងៗដែលយើងប្រើជាមួយ CSS APIs សម្រាប់ JavaScript គឺមិនត្រូវគ្នា។ ខ្ញុំបានបង្កើត API សំណួរដែលត្រូវគ្នា ដើម្បីឱ្យយើងចាប់ផ្តើម ទោះជាយ៉ាងនេះក្តី ខ្ញុំមិនបានគិតច្រើនទេ ព្រោះវាជាការចាកចេញពីអ្វីដែលយើងកំពុងធ្វើនៅទីនេះ។ នេះជាឧទាហរណ៍ការងារសាមញ្ញមួយនៃអ្នកបង្កើតសំណួរដែលអាចប្រើឡើងវិញបាន៖ សូមមើល Pen queryXPath [forked] ដោយ Bryan Rasmussen។ ខ្ញុំបានបន្ថែមវិធីសាស្រ្តពីរនៅលើវត្ថុឯកសារ៖ queryCSSSelectors (ដែលសំខាន់គឺ querySelectorAll) និង queryXPaths ។ ទាំងពីរនេះត្រឡប់វត្ថុសំណួរលទ្ធផល៖
{ queryType: nodes | ខ្សែអក្សរ | លេខ | ប៊ូលីន លទ្ធផល៖ any[] // ធាតុ html, ធាតុ xml, ខ្សែអក្សរ, លេខ, ប៊ូលីន, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }
មុខងារ queryCSSSelectors និង queryXpaths ដំណើរការសំណួរដែលអ្នកផ្តល់ឱ្យពួកគេលើធាតុនៅក្នុងអារេលទ្ធផល ដរាបណាអារេលទ្ធផលជាថ្នាំងប្រភេទ។ បើមិនដូច្នេះទេ វានឹងផ្តល់លទ្ធផល queryResult ជាមួយនឹងអារេទទេ និងប្រភេទថ្នាំង។ ប្រសិនបើការកែប្រែលក្ខណសម្បត្តិត្រូវបានកំណត់ទៅពិត មុខងារនឹងផ្លាស់ប្តូរ queryResults របស់ពួកគេផ្ទាល់។ មិនស្ថិតក្រោមកាលៈទេសៈណាក៏ដោយមិនគួរប្រើវានៅក្នុងបរិយាកាសផលិតកម្មទេ។ ខ្ញុំកំពុងធ្វើវាតាមវិធីនេះសុទ្ធសាធ ដើម្បីបង្ហាញពីផលប៉ះពាល់ផ្សេងៗនៃការប្រើប្រាស់ API សំណួរទាំងពីររួមគ្នា។ សំណួរឧទាហរណ៍ ខ្ញុំចង់បង្ហាញឧទាហរណ៍មួយចំនួននៃសំណួរ XPath ផ្សេងៗគ្នាដែលបង្ហាញពីអ្វីដែលមានឥទ្ធិពលមួយចំនួនដែលពួកគេអាចធ្វើបាន និងរបៀបដែលពួកគេអាចប្រើជំនួសវិធីសាស្រ្តផ្សេងទៀត។ ឧទាហរណ៍ទីមួយគឺ //li/text() ។ នេះសួរធាតុ li ទាំងអស់ ហើយត្រឡប់ថ្នាំងអត្ថបទរបស់ពួកគេ។ ដូច្នេះប្រសិនបើយើងចង់សួរ HTML ខាងក្រោម៖
- មួយ
- ពីរ
- បី
… នេះជាអ្វីដែលបានត្រឡប់មកវិញ៖
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
នៅក្នុងពាក្យផ្សេងទៀត យើងទទួលបានអារេដូចខាងក្រោម៖ ["មួយ","ពីរ","បី"]។ ជាធម្មតា អ្នកនឹងសួររកធាតុ li ដើម្បីទទួលបានវា បង្វែរលទ្ធផលនៃសំណួរនោះទៅជាអារេ គូសផែនទីអារេ ហើយត្រឡប់ថ្នាំងអត្ថបទនៃធាតុនីមួយៗ។ ប៉ុន្តែយើងអាចធ្វើវាឱ្យកាន់តែស៊ីជម្រៅជាមួយ XPath៖ document.queryXPaths("//li/text()") លទ្ធផល។
សូមកត់សម្គាល់ថាវិធីដើម្បីទទួលបានថ្នាំងអត្ថបទគឺប្រើអត្ថបទ () ដែលមើលទៅដូចជាហត្ថលេខាមុខងារ — ហើយវាគឺ។ វាត្រឡប់ថ្នាំងអត្ថបទនៃធាតុមួយ។ ក្នុងឧទាហរណ៍របស់យើង មានធាតុលីបីនៅក្នុងការសម្គាល់ ដែលនីមួយៗមានអត្ថបទ ("មួយ" "ពីរ" និង "បី")។
សូមក្រឡេកមើលឧទាហរណ៍មួយទៀតនៃសំណួរអត្ថបទ () ។ សន្មតថានេះគឺជាការសម្គាល់របស់យើង៖
តោះសរសេរសំណួរដែលត្រឡប់តម្លៃគុណលក្ខណៈ href៖ document.queryXPaths("//a[text() = 'ចូល']/@href").លទ្ធផល។
នេះគឺជាសំណួរ XPath នៅលើឯកសារបច្ចុប្បន្ន ដូចឧទាហរណ៍ចុងក្រោយដែរ ប៉ុន្តែលើកនេះ យើងត្រឡប់គុណលក្ខណៈ href នៃតំណភ្ជាប់ (ធាតុមួយ) ដែលមានអត្ថបទ “ចូល”។ ការពិតត្រឡប់មកវិញលទ្ធផលគឺ ["/login.html"] ។ ទិដ្ឋភាពទូទៅនៃមុខងារ XPath មានមុខងារ XPath មួយចំនួន ហើយអ្នកប្រហែលជាមិនស្គាល់ពួកវាទេ។ ខ្ញុំគិតថា មានរឿងមួយចំនួនដែលគួរដឹងអំពី រួមមានដូចខាងក្រោម៖
starts-withIf អត្ថបទចាប់ផ្តើមជាមួយឧទាហរណ៍អត្ថបទផ្សេងទៀតនោះ starts-with(@href, 'http:') ត្រឡប់ពិត ប្រសិនបើគុណលក្ខណៈ href ចាប់ផ្តើមដោយ http: ។ មានប្រសិនបើអត្ថបទមានឧទាហរណ៍អត្ថបទផ្សេងទៀត មាន(អត្ថបទ(), "ទស្សនាវដ្ដី Smashing") ត្រឡប់ពិត ប្រសិនបើថ្នាំងអត្ថបទមានពាក្យ "Smashing Magazine" នៅក្នុងវាគ្រប់ទីកន្លែង។ CountReturns រាប់ចំនួននៃការផ្គូផ្គងដែលមានចំពោះសំណួរមួយ។ ឧទាហរណ៍ រាប់(//*[starts-with(@href, 'http:']) ត្រឡប់ចំនួននៃចំនួនតំណភ្ជាប់នៅក្នុងថ្នាំងបរិបទមានធាតុដែលមានគុណលក្ខណៈ href ដែលមានអត្ថបទចាប់ផ្តើមដោយ http: ។ substring ធ្វើការដូចជាអក្សររង JavaScript លើកលែងតែអ្នកឆ្លងកាត់ខ្សែអក្សរជាអាគុយម៉ង់។ ឧទាហរណ៍ ខ្សែអក្សររង ("អត្ថបទរបស់ខ្ញុំ", 2, 4) ត្រឡប់ "y t" ។ substring-before ត្រឡប់ផ្នែកនៃខ្សែអក្សរមួយមុនខ្សែអក្សរផ្សេងទៀត។ ឧទាហរណ៍ substing-before("អត្ថបទរបស់ខ្ញុំ", "") ត្រឡប់ "my" ។ ដូចគ្នានេះដែរ ខ្សែអក្សររង-before("hi","bye") ត្រឡប់ខ្សែអក្សរទទេ។ substring-after ត្រឡប់ផ្នែកនៃខ្សែអក្សរបន្ទាប់ពីខ្សែអក្សរផ្សេងទៀត។ ឧទាហរណ៍ substing-after("អត្ថបទរបស់ខ្ញុំ", "") ត្រឡប់ "អត្ថបទ" ។ ស្រដៀងគ្នានេះដែរ ខ្សែអក្សររង-after("hi","bye") ត្រឡប់ខ្សែអក្សរទទេ។ normalize-space ត្រឡប់ខ្សែអក្សរអាគុយម៉ង់ជាមួយដកឃ្លាធម្មតាដោយការដកឃ្លានាំមុខ និងនៅពីក្រោយដកឃ្លា និងជំនួសលំដាប់តួអក្សរដកឃ្លាដោយដកឃ្លាតែមួយ។ notReturns a boolean true ប្រសិនបើអាគុយម៉ង់មិនពិត បើមិនដូច្នោះទេមិនពិត។ trueReturns ប៊ូលីនពិត។ falseReturns boolean false ។ concat រឿងដូចគ្នាទៅនឹង JavaScript concat លើកលែងតែអ្នកមិនដំណើរការវាជាវិធីសាស្រ្តនៅលើខ្សែអក្សរ។ ផ្ទុយទៅវិញ អ្នកដាក់ខ្សែទាំងអស់ដែលអ្នកចង់ភ្ជាប់។ string-length នេះមិនដូចគ្នានឹងប្រវែងខ្សែអក្សរ JavaScript ទេ ប៉ុន្តែត្រឡប់ប្រវែងខ្សែដែលវាត្រូវបានផ្ដល់ជាអាគុយម៉ង់។ បកប្រែនេះយកខ្សែអក្សរមួយ ហើយប្តូរអាគុយម៉ង់ទីពីរទៅជាអាគុយម៉ង់ទីបី។ ឧទាហរណ៍ បកប្រែ("abcdef", "abc", "XYZ") លទ្ធផល XYZdef ។
ក្រៅពីមុខងារ XPath ពិសេសទាំងនេះ មានមុខងារមួយចំនួនទៀតដែលដំណើរការដូចគ្នាទៅនឹងសមភាគី JavaScript របស់ពួកគេ — ឬសមភាគីនៅក្នុងភាសាសរសេរកម្មវិធីណាមួយ — ដែលអ្នកប្រហែលជាអាចរកឃើញមានប្រយោជន៍ផងដែរ ដូចជាជាន់ ពិដាន ជុំ បូកជាដើម។ ការបង្ហាញខាងក្រោមបង្ហាញពីមុខងារនីមួយៗនៃមុខងារទាំងនេះ៖ សូមមើលមុខងារលេខ Pen XPath [ forked ] ដោយ Bryan Rasmussen ។ ចំណាំថា ដូចជាមុខងាររៀបចំខ្សែអក្សរភាគច្រើន លេខជាច្រើនយកការបញ្ចូលតែមួយ។ នេះជាការពិតណាស់ ដោយសារតែពួកវាត្រូវបានគេសន្មត់ថាត្រូវបានប្រើសម្រាប់ការសួរសំណួរ ដូចនៅក្នុងឧទាហរណ៍ XPath ចុងក្រោយ៖ //li[floor(text())> 250]/@val
ប្រសិនបើអ្នកប្រើពួកវា ដូចដែលឧទាហរណ៍ភាគច្រើនធ្វើ អ្នកនឹងដំណើរការវានៅលើថ្នាំងដំបូងដែលត្រូវនឹងផ្លូវ។ វាក៏មានមុខងារបំប្លែងប្រភេទមួយចំនួនដែលអ្នកប្រហែលជាគួរជៀសវាងព្រោះ JavaScript មានបញ្ហាការបំប្លែងប្រភេទរបស់វារួចហើយ។ ប៉ុន្តែអាចមានពេលខ្លះដែលអ្នកចង់បំប្លែងខ្សែអក្សរទៅជាលេខ ដើម្បីពិនិត្យមើលវាធៀបនឹងលេខផ្សេងទៀត។ មុខងារដែលកំណត់ប្រភេទនៃអ្វីមួយគឺប៊ូលីន លេខ ខ្សែអក្សរ និងថ្នាំង។ ទាំងនេះគឺជាប្រភេទទិន្នន័យ XPath សំខាន់ៗ។ ហើយដូចដែលអ្នកប្រហែលជាស្រមៃ មុខងារទាំងនេះភាគច្រើនអាចប្រើលើប្រភេទទិន្នន័យដែលមិនមែនជាថ្នាំង DOM ។ ឧទាហរណ៍ ខ្សែអក្សររង-បន្ទាប់ពីយកខ្សែអក្សរ ដូចដែលយើងបានគ្របដណ្តប់រួចហើយ ប៉ុន្តែវាអាចជាខ្សែអក្សរពីគុណលក្ខណៈ href។ វាក៏អាចជាខ្សែអក្សរ៖
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
ជាក់ស្តែង ឧទាហរណ៍នេះនឹងផ្តល់ឱ្យយើងនូវលទ្ធផលអារេជា ["ពិភពលោក"]។ ដើម្បីបង្ហាញសកម្មភាពនេះ ខ្ញុំបានបង្កើតទំព័រសាកល្បងដោយប្រើមុខងារប្រឆាំងនឹងអ្វីដែលមិនមែនជាថ្នាំង DOM៖ សូមមើល Pen queryXPath [forked] ដោយ Bryan Rasmussen។ អ្នកគួរកត់សម្គាល់ពីទិដ្ឋភាពដ៏គួរឱ្យភ្ញាក់ផ្អើលនៃមុខងារបកប្រែ ដែលគឺថា ប្រសិនបើអ្នកមានតួអក្សរនៅក្នុងអាគុយម៉ង់ទីពីរ (ឧទាហរណ៍ បញ្ជីតួអក្សរដែលអ្នកចង់បកប្រែ) ហើយមិនមានតួអក្សរដែលត្រូវបកប្រែនោះ តួអក្សរនោះនឹងត្រូវដកចេញពីលទ្ធផល។ ដូច្នេះ នេះ៖
បកប្រែ('ជំរាបសួរ ឈ្មោះរបស់ខ្ញុំគឺ Inigo Montoya អ្នកបានសម្លាប់ឪពុករបស់ខ្ញុំ ត្រៀមខ្លួនដើម្បីស្លាប់','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…លទ្ធផលនៅក្នុងខ្សែអក្សរ រួមទាំងដកឃ្លា៖ [" * * ** "]
នេះមានន័យថាអក្សរ “a” កំពុងត្រូវបានបកប្រែទៅជាសញ្ញាផ្កាយ (*) ប៉ុន្តែរាល់តួអក្សរផ្សេងទៀតដែលមិនមានការបកប្រែដែលបានផ្តល់ឱ្យខ្សែអក្សរគោលដៅត្រូវបានដកចេញទាំងស្រុង។ ចន្លោះទទេគឺជាអ្វីដែលយើងបានចាកចេញរវាងតួអក្សរ "a" ដែលបានបកប្រែ។ បន្ទាប់មកម្តងទៀត សំណួរនេះ៖
បកប្រែ('ជំរាបសួរ ឈ្មោះរបស់ខ្ញុំគឺ Inigo Montoya អ្នកសម្លាប់ឪពុកខ្ញុំ រៀបចំស្លាប់','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,'*******************************************************)")
…មិនមានបញ្ហាទេ ហើយលទ្ធផលដែលមើលទៅដូចនេះ៖
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
វាអាចនឹងវាយប្រហារអ្នកថាមិនមានវិធីងាយស្រួលនៅក្នុង JavaScript ដើម្បីធ្វើអ្វីដែលមុខងារបកប្រែ XPath ធ្វើនោះទេ ទោះបីជាសម្រាប់ករណីប្រើប្រាស់ជាច្រើនក៏ដោយ ជំនួសទាំងអស់ជាមួយនឹងកន្សោមធម្មតាអាចដោះស្រាយវាបាន។ អ្នកអាចប្រើវិធីដូចគ្នាដែលខ្ញុំបានបង្ហាញ ប៉ុន្តែវាជាការប្រសើរបំផុតប្រសិនបើអ្នកចង់បានទាំងអស់គឺការបកប្រែខ្សែអក្សរ។ ការបង្ហាញខាងក្រោមបញ្ចប់មុខងារបកប្រែរបស់ XPath ដើម្បីផ្តល់កំណែ JavaScript៖ សូមមើលមុខងារបកប្រែ Pen [forked] ដោយ Bryan Rasmussen។ តើអ្នកអាចប្រើរបស់បែបនេះនៅឯណា? ពិចារណាលើការអ៊ិនគ្រីប Caesar Cipher ជាមួយនឹងអុហ្វសិតបីកន្លែង (ឧ. ការអ៊ិនគ្រីបកំពូលពី 48 B.C.)៖
បកប្រែ ("Caesar គ្រោងនឹងឆ្លងកាត់ Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
អត្ថបទបញ្ចូល "Caesar គ្រោងនឹងឆ្លងកាត់ Rubicon!" លទ្ធផលនៅក្នុង “Zxbpxo fp mixkkfkd ql zolpp ជ្រើសរើស Oryfzlk!” ដើម្បីផ្តល់ឧទាហរណ៍រហ័សមួយទៀតនៃលទ្ធភាពផ្សេងៗគ្នា ខ្ញុំបានបង្កើតមុខងារដែកដែលប្រើការបញ្ចូលខ្សែអក្សរ ហើយប្រើមុខងារបកប្រែដើម្បីត្រឡប់អត្ថបទ រួមទាំងតួអក្សរទាំងអស់ដែលយក umlauts ផងដែរ។ សូមមើលមុខងារ Pen metal [forked] ដោយ Bryan Rasmussen។
const metal = (str) => { return translation(str, "AOUaou","ÄÖÜäöü"); }
ហើយប្រសិនបើបានផ្តល់អត្ថបទថា "ច្បាប់ Motley Crue, 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 នៅលើថ្នាំងបរិបទដែលមិនមែនជាថ្នាំងរបស់ឯកសារ។ សូមមើល Pen css និង xpath រួមគ្នា [forked] ដោយ Bryan Rasmussen ។ CSS query គឺ .relatedarticles a ដែលទៅយកធាតុទាំងពីរក្នុង div ដែលបានចាត់ថ្នាក់ .relatedarticles។ បន្ទាប់ពីនោះគឺជាសំណួរ "អាក្រក់" ចំនួនបី ដែលមានន័យថា សំណួរដែលមិនធ្វើអ្វីដែលយើងចង់ឱ្យពួកគេធ្វើ នៅពេលដំណើរការជាមួយធាតុទាំងនេះជាថ្នាំងបរិបទ។ ខ្ញុំអាចពន្យល់ពីមូលហេតុដែលពួកគេមានអាកប្បកិរិយាខុសពីអ្នករំពឹងទុក។ សំណួរអាក្រក់បីនៅក្នុងសំណួរគឺ:
//text(): ត្រឡប់អត្ថបទទាំងអស់ក្នុងឯកសារ។ //a/text(): ត្រឡប់អត្ថបទទាំងអស់នៅខាងក្នុងនៃតំណភ្ជាប់ក្នុងឯកសារ។ ./a/text(): មិនបង្ហាញលទ្ធផលទេ។
ហេតុផលសម្រាប់លទ្ធផលទាំងនេះគឺថាខណៈពេលដែលបរិបទរបស់អ្នកគឺជាធាតុដែលត្រឡប់ពីសំណួរ CSS // ផ្ទុយនឹងឯកសារទាំងមូល។ នេះគឺជាកម្លាំងរបស់ XPath; CSS មិនអាចទៅពីថ្នាំងរហូតដល់បុព្វបុរសមួយ ហើយបន្ទាប់មកដល់បងប្អូនបង្កើតរបស់បុព្វបុរសនោះ ហើយដើរចុះទៅកាន់កូនចៅរបស់បងប្អូនបង្កើតនោះ។ ប៉ុន្តែ XPath អាចធ្វើបាន។ ទន្ទឹមនឹងនេះ ./ សួរកូនរបស់ថ្នាំងបច្ចុប្បន្ន ដែលចំនុច (.) តំណាងឱ្យថ្នាំងបច្ចុប្បន្ន ហើយសញ្ញាខាងមុខ (/) តំណាងឱ្យទៅថ្នាំងកូនមួយចំនួន — ថាតើវាជាគុណលក្ខណៈ ធាតុ ឬអត្ថបទត្រូវបានកំណត់ដោយផ្នែកបន្ទាប់នៃផ្លូវ។ ប៉ុន្តែមិនមានកូនជាធាតុដែលត្រូវបានជ្រើសរើសដោយសំណួរ CSS ទេ ដូច្នេះសំណួរនោះក៏មិនត្រឡប់អ្វីដែរ។ មានសំណួរល្អចំនួនបីនៅក្នុងការបង្ហាញចុងក្រោយនោះ៖
.//text(), ./text(), normalize-space./text())។
សំណួរ normalize-space បង្ហាញពីការប្រើប្រាស់មុខងារ XPath ប៉ុន្តែក៏ដោះស្រាយបញ្ហាដែលរួមបញ្ចូលនៅក្នុងសំណួរផ្សេងទៀតផងដែរ។ HTML ត្រូវបានរៀបចំដូចនេះ៖
ការធ្វើតេស្តមុខងាររបស់អ្នកដោយស្វ័យប្រវត្តិជាមួយនឹង Selenium WebDriver
សំណួរត្រឡប់មតិព័ត៌មានបន្ទាត់នៅដើម និងចុងនៃថ្នាំងអត្ថបទហើយ normalize-space យកវាចេញ។ ការប្រើប្រាស់មុខងារ XPath ណាមួយដែលផ្តល់លទ្ធផលអ្វីផ្សេងក្រៅពីប៊ូលីនជាមួយនឹងការបញ្ចូល XPath អនុវត្តចំពោះមុខងារផ្សេងទៀត។ ការបង្ហាញខាងក្រោមបង្ហាញពីឧទាហរណ៍មួយចំនួន៖ សូមមើលឧទាហរណ៍មុខងារ Pen xpath [forked] ដោយ Bryan Rasmussen ។ ឧទាហរណ៍ទីមួយបង្ហាញពីបញ្ហាដែលអ្នកគួរប្រយ័ត្ន។ ជាពិសេសលេខកូដខាងក្រោម៖
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 ដែរ។ ដូច្នេះ ប្រសិនបើយើងដឹងពីរចនាសម្ព័ន្ធ URL របស់ទស្សនាវដ្តី Smashing នោះ យើងអាចធ្វើដូចខាងក្រោម (ដោយប្រើអក្សរពុម្ពត្រូវបានណែនាំ)៖ `បកប្រែ( ខ្សែអក្សររង( substring-after./@href, 'www.smashingmagazine.com/') ,៩), '/','')`
វាស្មុគ្រស្មាញបន្តិចដល់កម្រិតដែលវាត្រូវការមតិដែលពិពណ៌នាអំពីអ្វីដែលវាធ្វើ៖ យក URL ទាំងអស់ចេញពីគុណលក្ខណៈ href បន្ទាប់ពី www.smashingmagazine.com/ យកតួអក្សរប្រាំបួនដំបូងចេញ បន្ទាប់មកបកប្រែសញ្ញាខាងមុខ (/) តួអក្សរទៅអ្វីទាំងអស់ ដើម្បីកម្ចាត់ការបញ្ចប់សញ្ញាខាងមុខ។ អារេលទ្ធផល៖
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
ករណីប្រើប្រាស់ XPath ច្រើនទៀត XPath ពិតជាអាចបញ្ចេញពន្លឺនៅក្នុងការធ្វើតេស្ត។ ហេតុផលមិនពិបាកមើលទេ ព្រោះ XPath អាចត្រូវបានប្រើដើម្បីទទួលបានរាល់ធាតុនៅក្នុង DOM ពីទីតាំងណាមួយនៅក្នុង DOM ចំណែក CSS មិនអាច។ អ្នកមិនអាចពឹងផ្អែកលើថ្នាក់ CSS ដែលនៅជាប់នឹងប្រព័ន្ធសាងសង់ទំនើបជាច្រើន ប៉ុន្តែជាមួយនឹង XPath យើងអាចធ្វើការផ្គូផ្គងកាន់តែរឹងមាំទៅនឹងខ្លឹមសារអត្ថបទនៃធាតុមួយ ដោយមិនគិតពីរចនាសម្ព័ន្ធ DOM ដែលកំពុងផ្លាស់ប្តូរ។ មានការស្រាវជ្រាវលើបច្ចេកទេសដែលអនុញ្ញាតឱ្យអ្នកធ្វើការធ្វើតេស្ត XPath ធន់។ គ្មានអ្វីអាក្រក់ជាងការសាកល្បង និងបរាជ័យដោយសារតែឧបករណ៍ជ្រើសរើស CSS លែងដំណើរការទេ ដោយសារអ្វីមួយត្រូវបានប្តូរឈ្មោះ ឬដកចេញ។ XPath ក៏ពិតជាអស្ចារ្យក្នុងការទាញយកទីតាំងច្រើនដែរ។ មានវិធីច្រើនជាងមួយដើម្បីប្រើសំណួរ XPath ដើម្បីផ្គូផ្គងធាតុមួយ។ ដូចគ្នានឹង CSS ដែរ។ ប៉ុន្តែសំណួរ XPath អាចចូលទៅក្នុងអ្វីៗក្នុងវិធីដែលមានគោលដៅកាន់តែខ្លាំងដែលកំណត់នូវអ្វីដែលទទួលបានមកវិញ ដោយអនុញ្ញាតឱ្យអ្នកស្វែងរកការផ្គូផ្គងជាក់លាក់ដែលអាចមានការប្រកួតដែលអាចធ្វើទៅបានជាច្រើន។ ជាឧទាហរណ៍ យើងអាចប្រើ XPath ដើម្បីត្រឡប់ធាតុ h2 ជាក់លាក់មួយដែលមាននៅខាងក្នុង div ដែលធ្វើតាម div បងប្អូនភ្លាមៗ ដែលនៅក្នុងវេនមានធាតុរូបភាពកុមារដែលមានគុណលក្ខណៈ data-testID="leader" នៅលើវា៖
កុំទទួលបានចំណងជើងនេះ
កុំទទួលបានចំណងជើងនេះផងដែរ
បឋមកថាសម្រាប់រូបភាពអ្នកដឹកនាំ
នេះជាសំណួរ៖ document.queryXPaths(` //div[ ដូចតទៅ៖:div[1] /img[@data-testID='អ្នកដឹកនាំ'] ] /h2/ អត្ថបទ() `);
តោះទស្សនាការបង្ហាញពីរបៀបដែលវាមកជាមួយទាំងអស់គ្នា៖ សូមមើល Pen Complex H2 Query [forked] ដោយ Bryan Rasmussen។ ដូច្នេះ បាទ។ មានផ្លូវជាច្រើនដែលអាចធ្វើទៅបានទៅកាន់ធាតុណាមួយនៅក្នុងការធ្វើតេស្តដោយប្រើ XPath ។ ការបដិសេធ XSLT 1.0 ខ្ញុំបានលើកឡើងពីដំបូងថាក្រុម Chrome គ្រោងនឹងដកការគាំទ្រ XSLT 1.0 ចេញពីកម្មវិធីរុករក។ នោះសំខាន់ព្រោះ XSLT 1.0 ប្រើកម្មវិធីផ្តោតលើ XML សម្រាប់ការបំប្លែងឯកសារ ដែលពឹងផ្អែកទៅលើ XPath 1.0 ដែលជាអ្វីដែលត្រូវបានរកឃើញនៅក្នុងកម្មវិធីរុករកភាគច្រើន។ នៅពេលដែលវាកើតឡើង យើងនឹងបាត់បង់សមាសធាតុសំខាន់នៃ XPath។ ប៉ុន្តែដោយសារការពិតថា XPath គឺពិតជាអស្ចារ្យសម្រាប់ការធ្វើតេស្តសរសេរ ខ្ញុំយល់ថា វាមិនទំនងថា XPath ទាំងមូលនឹងរលាយបាត់គ្រប់ពេលឆាប់ៗនេះទេ។ ដែលបាននិយាយថា ខ្ញុំបានកត់សម្គាល់ឃើញថា មនុស្សចាប់អារម្មណ៍លើមុខងារមួយ នៅពេលដែលវាត្រូវបានដកចេញ។ ហើយនោះជាការពិតនៅក្នុងករណីនៃ XSLT 1.0 ត្រូវបានបដិសេធ។ មានការពិភាក្សាទាំងស្រុងដែលកើតឡើងនៅលើព័ត៌មាន Hacker ដែលពោរពេញទៅដោយអំណះអំណាងប្រឆាំងនឹងការបដិសេធ។ ប្រកាសខ្លួនឯងគឺជាឧទាហរណ៍ដ៏អស្ចារ្យនៃការបង្កើតក្របខ័ណ្ឌប្លុកជាមួយ XSLT ។ អ្នកអាចអានការពិភាក្សាសម្រាប់ខ្លួនអ្នក ប៉ុន្តែវាចូលទៅក្នុងរបៀបដែល JavaScript អាចត្រូវបានប្រើជា shim សម្រាប់ XLST ដើម្បីដោះស្រាយប្រភេទនៃករណីទាំងនោះ។ ខ្ញុំក៏បានឃើញការណែនាំដែលកម្មវិធីរុករកគួរតែប្រើ SaxonJS ដែលជាច្រកទៅកាន់ម៉ាស៊ីន Saxon XSLT, XQUERY និង XPath របស់ JavaScript។ នោះជាគំនិតគួរឱ្យចាប់អារម្មណ៍មួយ ជាពិសេសនៅពេលដែល Saxon-JS អនុវត្តកំណែបច្ចុប្បន្ននៃលក្ខណៈបច្ចេកទេសទាំងនេះ ខណៈពេលដែលមិនមានកម្មវិធីរុករកណាមួយដែលអនុវត្តកំណែ XPath ឬ XSLT លើសពី 1.0 ហើយមិនមានកម្មវិធីណាមួយដែលអនុវត្ត XQuery នោះទេ។ ខ្ញុំបានទាក់ទង Norm Tovey-Walsh នៅ Saxonica ដែលជាក្រុមហ៊ុននៅពីក្រោយ SaxonJS និងកំណែផ្សេងទៀតនៃម៉ាស៊ីន Saxon ។ គាត់បាននិយាយថា: "ប្រសិនបើអ្នកលក់កម្មវិធីរុករកតាមអ៊ីនធឺណិតណាមួយចាប់អារម្មណ៍ក្នុងការយក SaxonJS ជាចំណុចចាប់ផ្តើមសម្រាប់ការរួមបញ្ចូលបច្ចេកវិទ្យា XML ទំនើបទៅក្នុងកម្មវិធីរុករកនោះ យើងនឹងរីករាយក្នុងការពិភាក្សាជាមួយពួកគេ។"— Norm Tovey-Walsh
ប៉ុន្តែក៏បានបន្ថែមថា៖ "ខ្ញុំនឹងភ្ញាក់ផ្អើលខ្លាំងណាស់ប្រសិនបើនរណាម្នាក់គិតថាការយក SaxonJS នៅក្នុងទម្រង់បច្ចុប្បន្នរបស់វា ហើយទម្លាក់វាទៅក្នុង browser build unchanged នឹងក្លាយជាវិធីសាស្រ្តដ៏ល្អ។ អ្នកលក់ browser តាមធម្មជាតិនៃការពិតដែលថាពួកគេបង្កើត browser អាចចូលទៅដល់ការរួមបញ្ចូលនៅកម្រិតជ្រៅជាងយើងអាច "ពីខាងក្រៅ" ។— Norm Tovey-Walsh
វាគួរឱ្យកត់សម្គាល់ថាការអត្ថាធិប្បាយរបស់ Tovey-Walsh បានកើតឡើងប្រហែលមួយសប្តាហ៍មុនពេលការប្រកាសបដិសេធ XSLT ។ សេចក្តីសន្និដ្ឋាន ខ្ញុំអាចបន្តទៅមុខទៀត។ ប៉ុន្តែខ្ញុំសង្ឃឹមថាវាបានបង្ហាញពីថាមពលរបស់ XPath និងបានផ្តល់ឱ្យអ្នកនូវឧទាហរណ៍ជាច្រើនដែលបង្ហាញពីរបៀបប្រើវាដើម្បីសម្រេចបាននូវរឿងអស្ចារ្យ។ វាជាឧទាហរណ៍ដ៏ល្អឥតខ្ចោះនៃបច្ចេកវិទ្យាចាស់នៅក្នុងបណ្តុំកម្មវិធីរុករកដែលនៅតែមានឧបករណ៍ប្រើប្រាស់ច្រើននាពេលបច្ចុប្បន្ននេះ ទោះបីជាអ្នកមិនដែលដឹងថាវាមាន ឬមិនធ្លាប់គិតដល់ការស្វែងរកវាក៏ដោយ។ ការអានបន្ថែម
"ការបង្កើនភាពធន់នៃការធ្វើតេស្តគេហទំព័រដោយស្វ័យប្រវត្តិជាមួយនឹងភាសាធម្មជាតិ" (បណ្ណាល័យឌីជីថល ACM) ដោយ Maroun Ayli, Youssef Bakouny, Nader Jalloul និង Rima Kilany អត្ថបទនេះផ្តល់នូវឧទាហរណ៍ XPath ជាច្រើនសម្រាប់ការសរសេរការធ្វើតេស្តធន់។ XPath (MDN)នេះគឺជាកន្លែងដ៏ល្អមួយដើម្បីចាប់ផ្តើមប្រសិនបើអ្នកចង់បានការពន្យល់បច្ចេកទេសដែលលម្អិតអំពីរបៀបដែល XPath ដំណើរការ។ XPath Tutorial (ZVON)ខ្ញុំបានរកឃើញការបង្រៀននេះមានប្រយោជន៍បំផុតក្នុងការរៀនរបស់ខ្ញុំ ដោយសារឧទាហរណ៍ជាច្រើន និងការពន្យល់ច្បាស់លាស់។ XPather ឧបករណ៍អន្តរកម្មនេះអនុញ្ញាតឱ្យអ្នកធ្វើការដោយផ្ទាល់ជាមួយកូដ។
