ຂ້າພະເຈົ້າໄດ້ຢູ່ໃນການພັດທະນາດ້ານຫນ້າເປັນເວລາດົນນານພຽງພໍທີ່ຈະເຫັນທ່າອ່ຽງໃນຫລາຍປີທີ່ຜ່ານມາ: ນັກພັດທະນາຫນຸ່ມທີ່ເຮັດວຽກກັບແບບແຜນໃຫມ່ຂອງການຂຽນໂປລແກລມໂດຍບໍ່ເຂົ້າໃຈສະພາບປະຫວັດສາດຂອງມັນ. ມັນແມ່ນ, ແນ່ນອນ, ເຂົ້າໃຈຢ່າງສົມບູນທີ່ຈະບໍ່ຮູ້ບາງສິ່ງບາງຢ່າງ. ເວັບໄຊຕ໌ເປັນສະຖານທີ່ໃຫຍ່ຫຼາຍທີ່ມີຊຸດທັກສະແລະຄວາມພິເສດທີ່ຫຼາກຫຼາຍ, ແລະພວກເຮົາບໍ່ເຄີຍຮູ້ສິ່ງທີ່ພວກເຮົາບໍ່ຮູ້. ການຮຽນຮູ້ໃນສາຂານີ້ແມ່ນການເດີນທາງຢ່າງຕໍ່ເນື່ອງແທນທີ່ຈະເປັນສິ່ງທີ່ເກີດຂຶ້ນຄັ້ງດຽວແລະສິ້ນສຸດ. ໃນກໍລະນີ: ບາງຄົນໃນທີມງານຂອງຂ້ອຍໄດ້ຖາມວ່າມັນເປັນໄປໄດ້ທີ່ຈະບອກໄດ້ວ່າຜູ້ໃຊ້ທ່ອງໄປຫາແຖບໃດນຶ່ງໃນ UI. ຂ້າພະເຈົ້າໄດ້ຊີ້ໃຫ້ເຫັນເຫດການ JavaScript ກ່ອນ unload. ແຕ່ຜູ້ທີ່ໄດ້ແກ້ໄຂບັນຫານີ້ກ່ອນທີ່ຈະຮູ້ວ່ານີ້ແມ່ນເປັນໄປໄດ້ຍ້ອນວ່າພວກເຂົາໄດ້ຮັບການຕີກັບການແຈ້ງເຕືອນກ່ຽວກັບຂໍ້ມູນທີ່ບໍ່ໄດ້ບັນທຶກໄວ້ໃນເວັບໄຊທ໌ອື່ນໆ, ເຊິ່ງກ່ອນ unload ເປັນກໍລະນີທີ່ໃຊ້ທົ່ວໄປ. ຂ້າພະເຈົ້າຍັງໄດ້ຊີ້ໃຫ້ເຫັນ pageHide ແລະ visibilityChange ເຫດການກັບເພື່ອນຮ່ວມງານຂອງຂ້າພະເຈົ້າສໍາລັບການວັດແທກທີ່ດີ. ຂ້ອຍຮູ້ໄດ້ແນວໃດກ່ຽວກັບເລື່ອງນັ້ນ? ເນື່ອງຈາກວ່າມັນເກີດຂື້ນໃນໂຄງການອື່ນ, ບໍ່ແມ່ນຍ້ອນວ່າຂ້ອຍໄດ້ສຶກສາກ່ຽວກັບມັນໃນຕອນເລີ່ມຕົ້ນຮຽນ JavaScript. ຄວາມຈິງແລ້ວແມ່ນວ່າກອບດ້ານຫນ້າທີ່ທັນສະໄຫມແມ່ນຢືນຢູ່ເທິງບ່າຂອງຍັກໃຫຍ່ເຕັກໂນໂລຢີທີ່ນໍາຫນ້າພວກເຂົາ. ພວກເຂົາປະຕິບັດການພັດທະນາແບບບໍ່ມີຕົວຕົນ, ເລື້ອຍໆສໍາລັບປະສົບການຂອງນັກພັດທະນາທີ່ດີກວ່າທີ່ຫຼຸດຜ່ອນ, ຫຼືແມ້ກະທັ້ງການລົບລ້າງ, ຄວາມຕ້ອງການທີ່ຈະຮູ້ຫຼືສໍາຜັດກັບສິ່ງທີ່ເປັນແນວຄວາມຄິດດ້ານຫນ້າທີ່ສໍາຄັນທີ່ທຸກຄົນຄວນຈະຮູ້. ພິຈາລະນາ CSS Object Model (CSSOM). ທ່ານອາດຈະຄາດຫວັງວ່າຜູ້ໃດທີ່ເຮັດວຽກໃນ CSS ແລະ JavaScript ມີປະສົບການ CSSOM ທີ່ມີມື, ແຕ່ນັ້ນບໍ່ແມ່ນສະເຫມີໄປ. ມີໂຄງການ React ສໍາລັບເວັບໄຊທ໌ອີຄອມເມີຊທີ່ຂ້ອຍເຮັດວຽກຢູ່ບ່ອນທີ່ພວກເຮົາຕ້ອງການໂຫລດ stylesheet ສໍາລັບຜູ້ໃຫ້ບໍລິການການຈ່າຍເງິນທີ່ເລືອກໃນປັດຈຸບັນ. ບັນຫາແມ່ນວ່າ stylesheet ກໍາລັງໂຫລດຢູ່ໃນທຸກໆຫນ້າໃນເວລາທີ່ມັນຕ້ອງການພຽງແຕ່ຢູ່ໃນຫນ້າສະເພາະ. ຜູ້ພັດທະນາທີ່ມອບໝາຍໃຫ້ເຮັດອັນນີ້ເກີດຂຶ້ນບໍ່ເຄີຍໄດ້ໂຫຼດແຜ່ນສະໄຕລ໌ແບບໄດນາມິກເທື່ອ. ອີກເທື່ອຫນຶ່ງ, ນີ້ແມ່ນເຂົ້າໃຈໄດ້ຢ່າງສົມບູນເມື່ອ React abstracts ຫ່າງວິທີການແບບດັ້ງເດີມທີ່ທ່ານອາດຈະບັນລຸໄດ້. CSSOM ອາດຈະບໍ່ແມ່ນສິ່ງທີ່ທ່ານຕ້ອງການໃນວຽກງານປະຈໍາວັນຂອງທ່ານ. ແຕ່ມັນເປັນໄປໄດ້ວ່າເຈົ້າຈະຕ້ອງພົວພັນກັບມັນໃນບາງຈຸດ, ເຖິງແມ່ນວ່າຢູ່ໃນຕົວຢ່າງດຽວ. ປະສົບການເຫຼົ່ານີ້ໄດ້ດົນໃຈໃຫ້ຂ້ອຍຂຽນບົດຄວາມນີ້. ມີຫຼາຍລັກສະນະເວັບ ແລະເທກໂນໂລຍີທີ່ມີຢູ່ໃນທໍາມະຊາດທີ່ເຈົ້າອາດບໍ່ເຄີຍສໍາຜັດໂດຍກົງໃນການເຮັດວຽກປະຈໍາວັນຂອງເຈົ້າ. ບາງທີເຈົ້າເປັນຄົນໃໝ່ພໍສົມຄວນໃນການພັດທະນາເວັບ ແລະພຽງແຕ່ບໍ່ຮູ້ຈັກພວກມັນເພາະວ່າເຈົ້າຢູ່ໃນຄວາມຂາດເຂີນຂອງກອບສະເພາະທີ່ບໍ່ຮຽກຮ້ອງໃຫ້ເຈົ້າຮູ້ມັນເລິກເຊິ່ງ, ຫຼືແມ້ແຕ່ຢູ່ໃນທັງໝົດ. ຂ້ອຍເວົ້າສະເພາະກ່ຽວກັບ XML, ເຊິ່ງພວກເຮົາຫຼາຍຄົນຮູ້ວ່າເປັນພາສາບູຮານທີ່ບໍ່ຄ້າຍຄືກັນກັບ HTML. ຂ້ອຍໄດ້ຍົກເລື່ອງນີ້ຂຶ້ນເນື່ອງຈາກການສົນທະນາຂອງ WHATWG ທີ່ຜ່ານມາໄດ້ແນະນໍາວ່າຊິ້ນສ່ວນທີ່ສໍາຄັນຂອງ XML stack ທີ່ເອີ້ນວ່າການຂຽນໂປລແກລມ XSLT ຄວນຖືກລຶບອອກຈາກຕົວທ່ອງເວັບ. ນີ້ແມ່ນສິ່ງທີ່ເກົ່າແກ່, ເຕັກໂນໂລຢີທີ່ມີຢູ່ແລ້ວທີ່ພວກເຮົາເຄີຍມີມາເປັນເວລາຫລາຍປີທີ່ສາມາດນໍາໃຊ້ໄດ້ກັບສິ່ງທີ່ປະຕິບັດໄດ້ຄືກັບສະຖານະການ CSSOM ທີ່ທີມງານຂອງຂ້ອຍຢູ່ໃນ. ເຈົ້າເຄີຍເຮັດວຽກກັບ XSLT ມາກ່ອນບໍ? ໃຫ້ເບິ່ງວ່າພວກເຮົາເອື່ອຍອີງຫຼາຍເຂົ້າໄປໃນເຕັກໂນໂລຢີທີ່ເກົ່າແກ່ນີ້ແລະນໍາໃຊ້ຄຸນສົມບັດຂອງມັນນອກຂອບເຂດຂອງ XML ເພື່ອແກ້ໄຂບັນຫາໃນໂລກທີ່ແທ້ຈິງໃນມື້ນີ້. XPath: API ກາງ ເທກໂນໂລຍີ XML ທີ່ສໍາຄັນທີ່ສຸດທີ່ບາງທີອາດເປັນປະໂຫຍດທີ່ສຸດຢູ່ນອກມຸມເບິ່ງ XML ກົງແມ່ນ XPath, ພາສາແບບສອບຖາມທີ່ຊ່ວຍໃຫ້ທ່ານຊອກຫາ node ຫຼືຄຸນລັກສະນະໃດໆໃນ markup tree ທີ່ມີອົງປະກອບຮາກຫນຶ່ງ. ຂ້ອຍມີຄວາມຮັກສ່ວນຕົວຕໍ່ 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 queries ອົງປະກອບທີ່ມີ .myClass classname. ໃນຂະນະດຽວກັນ, ອົງປະກອບການສອບຖາມຕົວຢ່າງ XPath ທີ່ມີຫ້ອງຮຽນຄຸນລັກສະນະທີ່ມີສາຍ "myClass". ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນເລືອກອົງປະກອບທີ່ມີ myClass ໃນຄຸນລັກສະນະໃດກໍ່ຕາມ, ລວມທັງອົງປະກອບທີ່ມີຊື່ຫ້ອງຮຽນ .myClass — ເຊັ່ນດຽວກັນກັບອົງປະກອບທີ່ມີ "myClass" ໃນສະຕຣິງເຊັ່ນ .myClass2. XPath ແມ່ນກວ້າງກວ່າໃນຄວາມຫມາຍນັ້ນ. ດັ່ງນັ້ນ, ບໍ່. ຂ້າພະເຈົ້າບໍ່ໄດ້ແນະນໍາວ່າພວກເຮົາຄວນຈະຖິ້ມ CSS ແລະເລີ່ມເລືອກອົງປະກອບທັງຫມົດຜ່ານ XPath. ນັ້ນບໍ່ແມ່ນຈຸດ. ຈຸດແມ່ນວ່າ XPath ສາມາດເຮັດສິ່ງທີ່ CSS ບໍ່ສາມາດເຮັດໄດ້ແລະຍັງສາມາດເປັນປະໂຫຍດຫຼາຍ, ເຖິງແມ່ນວ່າມັນເປັນເທກໂນໂລຍີເກົ່າແກ່ໃນ stack browser ແລະອາດຈະບໍ່ເຫັນໄດ້ຊັດເຈນຢູ່ glance ທໍາອິດ. ໃຫ້ພວກເຮົາໃຊ້ສອງເທກໂນໂລຍີຮ່ວມກັນບໍ່ພຽງແຕ່ຍ້ອນວ່າພວກເຮົາສາມາດເຮັດໄດ້, ແຕ່ຍ້ອນວ່າພວກເຮົາຈະຮຽນຮູ້ບາງຢ່າງກ່ຽວກັບ XPath ໃນຂະບວນການ, ເຮັດໃຫ້ມັນເປັນເຄື່ອງມືອື່ນໃນ stack ຂອງທ່ານ - ຫນຶ່ງທີ່ທ່ານອາດຈະບໍ່ເຄີຍຮູ້ຈັກມີມາຕະຫຼອດ! ບັນຫາແມ່ນວ່າວິທີການ document.evaluate ຂອງ JavaScript ແລະວິທີການເລືອກແບບສອບຖາມຕ່າງໆທີ່ພວກເຮົາໃຊ້ກັບ CSS APIs ສໍາລັບ JavaScript ແມ່ນບໍ່ເຂົ້າກັນໄດ້. ຂ້ອຍໄດ້ເຮັດ API ການສອບຖາມທີ່ເຂົ້າກັນໄດ້ເພື່ອໃຫ້ພວກເຮົາເລີ່ມຕົ້ນ, ເຖິງແມ່ນວ່າຍອມຮັບຢ່າງຈິງ, ຂ້ອຍບໍ່ໄດ້ຄິດກ່ຽວກັບມັນຫຼາຍເພາະວ່າມັນເປັນການອອກຈາກສິ່ງທີ່ພວກເຮົາເຮັດຢູ່ທີ່ນີ້. ນີ້ແມ່ນຕົວຢ່າງການເຮັດວຽກທີ່ງ່າຍດາຍຂອງຕົວສ້າງແບບສອບຖາມທີ່ໃຊ້ຄືນໄດ້: ເບິ່ງ Pen queryXPath [forked] ໂດຍ Bryan Rasmussen. ຂ້ອຍໄດ້ເພີ່ມສອງວິທີໃນວັດຖຸເອກະສານ: queryCSSSelectors (ເຊິ່ງສໍາຄັນແມ່ນ querySelectorAll) ແລະ queryXPaths. ທັງສອງອັນນີ້ສົ່ງຄືນວັດຖຸ queryResults:
{ queryType: nodes | ຊ່ອຍແນ່ | ເລກ | ບູລີນ, ຜົນໄດ້ຮັບ: any[] // ອົງປະກອບ html, ອົງປະກອບ xml, strings, ຕົວເລກ, booleans, queryCSSSelectors: (ສອບຖາມ: string, ແກ້ໄຂ: boolean) => queryResults, queryXpaths: (ສອບຖາມ: string, ແກ້ໄຂ: boolean) => queryResults }
ຟັງຊັນ queryCSSSelectors ແລະ queryXpaths ດໍາເນີນການສອບຖາມທີ່ທ່ານໃຫ້ມັນຫຼາຍກວ່າອົງປະກອບໃນ array ຜົນໄດ້ຮັບ, ຕາບໃດທີ່ array ຜົນໄດ້ຮັບແມ່ນປະເພດ nodes, ແນ່ນອນ. ຖ້າບໍ່ດັ່ງນັ້ນ, ມັນຈະສົ່ງຄືນ queryResult ກັບ array ຫວ່າງເປົ່າແລະປະເພດຂອງ nodes. ຖ້າຄຸນສົມບັດແກ້ໄຂຖືກຕັ້ງເປັນຖືກຕ້ອງ, ຟັງຊັນຕ່າງໆຈະປ່ຽນຜົນການສອບຖາມຂອງຕົນເອງ. ພາຍໃຕ້ສະພາບການນີ້ບໍ່ຄວນໃຊ້ໃນສະພາບແວດລ້ອມການຜະລິດ. ຂ້ອຍກໍາລັງເຮັດມັນດ້ວຍວິທີນີ້ຢ່າງດຽວເພື່ອສະແດງໃຫ້ເຫັນຜົນກະທົບຕ່າງໆຂອງການໃຊ້ API ຄໍາຖາມສອງອັນຮ່ວມກັນ. ຕົວຢ່າງແບບສອບຖາມ ຂ້ອຍຕ້ອງການສະແດງຕົວຢ່າງບາງຢ່າງຂອງການສອບຖາມ XPath ທີ່ແຕກຕ່າງກັນທີ່ສະແດງໃຫ້ເຫັນບາງສິ່ງທີ່ມີອໍານາດທີ່ເຂົາເຈົ້າສາມາດເຮັດໄດ້ແລະວິທີການທີ່ພວກເຂົາສາມາດຖືກນໍາໃຊ້ແທນວິທີການອື່ນໆ. ຕົວຢ່າງທໍາອິດແມ່ນ //li/text(). ນີ້ຈະສອບຖາມອົງປະກອບ li ທັງໝົດ ແລະສົ່ງຄືນຂໍ້ຄວາມຂໍ້ຄວາມຂອງເຂົາເຈົ້າ. ດັ່ງນັ້ນ, ຖ້າພວກເຮົາຕ້ອງການສອບຖາມ HTML ຕໍ່ໄປນີ້:
- ຫນຶ່ງ
- ສອງ
- ສາມ
…ນີ້ແມ່ນສິ່ງທີ່ໄດ້ກັບຄືນມາ:
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາໄດ້ຮັບ array ດັ່ງຕໍ່ໄປນີ້: ["ຫນຶ່ງ", "ສອງ", "ສາມ"]. ໂດຍປົກກະຕິ, ທ່ານຈະສອບຖາມສໍາລັບອົງປະກອບ li ເພື່ອໃຫ້ໄດ້ຮັບສິ່ງນັ້ນ, ປ່ຽນຜົນຂອງການສອບຖາມນັ້ນເຂົ້າໄປໃນ array, ສ້າງແຜນທີ່ array, ແລະສົ່ງຄືນຂໍ້ຄວາມຂອງແຕ່ລະອົງປະກອບ. ແຕ່ພວກເຮົາສາມາດເຮັດສິ່ງນັ້ນໄດ້ຊັດເຈນກວ່າກັບ XPath: document.queryXPaths("//li/text()").ຜົນໄດ້ຮັບ.
ສັງເກດເຫັນວ່າວິທີການທີ່ຈະໄດ້ຮັບຂໍ້ຄວາມແມ່ນການນໍາໃຊ້ຂໍ້ຄວາມ (), ເຊິ່ງຄ້າຍຄືກັບລາຍເຊັນຂອງຫນ້າທີ່ - ແລະມັນແມ່ນ. ມັນສົ່ງຄືນຂໍ້ຄວາມຂອງອົງປະກອບໃດໜຶ່ງ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ມີສາມອົງປະກອບ li ໃນ markup, ແຕ່ລະມີຂໍ້ຄວາມ ("ຫນຶ່ງ", "ສອງ" ແລະ "ສາມ").
ໃຫ້ເບິ່ງຕົວຢ່າງເພີ່ມເຕີມຂອງຂໍ້ຄວາມ () ຄໍາຖາມ. ຖືວ່ານີ້ແມ່ນເຄື່ອງໝາຍຂອງພວກເຮົາ:
ໃຫ້ຂຽນຄໍາຖາມທີ່ສົ່ງຄືນຄ່າຄຸນສົມບັດ href: document.queryXPaths("//a[text() = 'ເຂົ້າສູ່ລະບົບ']/@href").ຜົນໄດ້ຮັບ.
ນີ້ແມ່ນການສອບຖາມ XPath ໃນເອກະສານປະຈຸບັນ, ຄືກັນກັບຕົວຢ່າງທີ່ຜ່ານມາ, ແຕ່ເວລານີ້ພວກເຮົາສົ່ງຄືນຄຸນລັກສະນະ href ຂອງການເຊື່ອມຕໍ່ (ອົງປະກອບ) ທີ່ມີຂໍ້ຄວາມ "ເຂົ້າສູ່ລະບົບ". ຕົວຈິງກັບຄືນມາຜົນໄດ້ຮັບແມ່ນ ["/login.html"]. ພາບລວມຂອງຟັງຊັນ XPath ມີຫຼາຍຟັງຊັນ XPath, ແລະທ່ານອາດຈະບໍ່ຄຸ້ນເຄີຍກັບພວກມັນ. ຂ້າພະເຈົ້າຄິດວ່າ, ມີຫຼາຍສິ່ງທີ່ຄວນຮູ້, ລວມທັງດັ່ງຕໍ່ໄປນີ້:
starts-withIf ຂໍ້ຄວາມເລີ່ມຕົ້ນດ້ວຍຕົວຢ່າງຂໍ້ຄວາມອື່ນໆໂດຍສະເພາະ, starts-with(@href, 'http:') ກັບຄືນຄວາມຈິງຖ້າຄຸນລັກສະນະ href ເລີ່ມຕົ້ນດ້ວຍ http:. containers ຖ້າຂໍ້ຄວາມມີຕົວຢ່າງຂໍ້ຄວາມອື່ນໆໂດຍສະເພາະ, ມີ (ຂໍ້ຄວາມ (), "Smashing Magazine") ກັບຄືນຄວາມຈິງຖ້າຂໍ້ຄວາມມີຄໍາວ່າ "Smashing Magazine" ຢູ່ໃນບ່ອນໃດກໍ່ຕາມ. countReturns ການນັບຈໍານວນທີ່ກົງກັນກັບຄໍາຖາມ. ຕົວຢ່າງ, count(//*[starts-with(@href, 'http:']) ສົ່ງຄືນການນັບຈໍານວນການເຊື່ອມຕໍ່ໃນ context node ມີອົງປະກອບທີ່ມີຄຸນລັກສະນະ href ທີ່ມີຂໍ້ຄວາມເລີ່ມຕົ້ນດ້ວຍ http:. substring ເຮັດວຽກຄືກັບ JavaScript substring, ຍົກເວັ້ນທ່ານຜ່ານ string ເປັນການໂຕ້ຖຽງ. ຕົວຢ່າງ, substring("ຂໍ້ຄວາມຂອງຂ້ອຍ", 2, 4) ຕອບ "y t". substring-beforeReturns ສ່ວນຂອງ string ກ່ອນ string ອື່ນ. ສໍາລັບຕົວຢ່າງ, substing-before("ຂໍ້ຄວາມຂອງຂ້ອຍ", "") ກັບ "ຂອງຂ້ອຍ". ເຊັ່ນດຽວກັນ, substring-before("hi","bye") ຕອບສະຕຣິງຫວ່າງເປົ່າ. substring-afterReturns ສ່ວນຂອງ string ຫຼັງຈາກ string ອື່ນ. ສໍາລັບຕົວຢ່າງ, substing-after ("ຂໍ້ຄວາມຂອງຂ້ອຍ", "") ສົ່ງຄືນ "ຂໍ້ຄວາມ". ເຊັ່ນດຽວກັນ, substring-after("hi","bye")ຕອບສະຕຣິງຫວ່າງເປົ່າ. normalize-spaceReturns the argument string with whitespace normalized by stripping leading and trailing whitespace and replace the sequences of whitespace characters by a single space. not returns a boolean true ຖ້າ argument ເປັນ false, ຖ້າບໍ່ດັ່ງນັ້ນ false. trueReturns boolean true. falseReturns boolean false. concat ສິ່ງດຽວກັນກັບ JavaScript concat, ເວັ້ນເສຍແຕ່ວ່າທ່ານບໍ່ໄດ້ດໍາເນີນການມັນເປັນວິທີການຢູ່ໃນສະຕຣິງ. ແທນທີ່ຈະ, ເຈົ້າໃສ່ສາຍທັງໝົດທີ່ເຈົ້າຕ້ອງການເຂົ້າກັນ. string-length ອັນນີ້ບໍ່ຄືກັບ JavaScript string-length, ແຕ່ສົ່ງຄືນຄວາມຍາວຂອງ string ທີ່ມັນຖືກມອບໃຫ້ເປັນ argument. ແປຄຳອະທິບາຍກັບຄືນເປັນ ອັງກິດ (ສະຫະລັດ) ແປພາສາ This take a string and change the second argument to the third argument. ຕົວຢ່າງ, ແປ ("abcdef", "abc", "XYZ") ຜົນໄດ້ຮັບ XYZdef.
ນອກ ເໜືອ ໄປຈາກຟັງຊັນ XPath ເຫຼົ່ານີ້, ມີ ໜ້າ ທີ່ອື່ນໆທີ່ເຮັດວຽກຄືກັນກັບຄູ່ JavaScript ຂອງພວກເຂົາ - ຫຼືຄູ່ຮ່ວມງານໃນພາສາການຂຽນໂປຼແກຼມໃດໆ - ທີ່ທ່ານອາດຈະຊອກຫາທີ່ເປັນປະໂຫຍດ, ເຊັ່ນ: ຊັ້ນ, ເພດານ, ຮອບ, ລວມ, ແລະອື່ນໆ. ການສາທິດຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນແຕ່ລະຫນ້າທີ່ເຫຼົ່ານີ້: ເບິ່ງຫນ້າທີ່ Pen XPath Numerical [forked] ໂດຍ Bryan Rasmussen. ຈົ່ງຈື່ໄວ້ວ່າ, ເຊັ່ນດຽວກັບຫນ້າທີ່ການຫມູນໃຊ້ສະຕຣິງສ່ວນໃຫຍ່, ຕົວເລກຈໍານວນຫຼາຍເອົາການປ້ອນຂໍ້ມູນດຽວ. ນີ້ແມ່ນແນ່ນອນ, ເພາະວ່າພວກມັນຖືກໃຊ້ສໍາລັບການສອບຖາມ, ເຊັ່ນດຽວກັບຕົວຢ່າງ XPath ສຸດທ້າຍ: //li[floor(text()) > 250]/@val
ຖ້າທ່ານໃຊ້ພວກມັນ, ດັ່ງທີ່ຕົວຢ່າງສ່ວນໃຫຍ່ເຮັດ, ທ່ານຈະສິ້ນສຸດການແລ່ນມັນຢູ່ໃນໂຫນດທໍາອິດທີ່ກົງກັບເສັ້ນທາງ. ຍັງມີບາງຫນ້າທີ່ການແປງປະເພດທີ່ທ່ານຄວນຫຼີກເວັ້ນເພາະວ່າ JavaScript ມີບັນຫາການແປງປະເພດຂອງຕົນເອງແລ້ວ. ແຕ່ສາມາດມີບາງຄັ້ງທີ່ທ່ານຕ້ອງການທີ່ຈະປ່ຽນສະຕຣິງເປັນຕົວເລກເພື່ອກວດເບິ່ງມັນທຽບກັບຕົວເລກອື່ນ. ຟັງຊັນທີ່ກໍານົດປະເພດຂອງບາງສິ່ງບາງຢ່າງແມ່ນ boolean, ຕົວເລກ, string, ແລະ node. ເຫຼົ່ານີ້ແມ່ນປະເພດຂໍ້ມູນ XPath ທີ່ສໍາຄັນ. ແລະຕາມທີ່ເຈົ້າອາດຈະຈິນຕະນາການ, ຫນ້າທີ່ເຫຼົ່ານີ້ສ່ວນໃຫຍ່ສາມາດຖືກນໍາໃຊ້ໃນປະເພດຂໍ້ມູນທີ່ບໍ່ແມ່ນ DOM nodes. ຕົວຢ່າງ, substring-after ໃຊ້ເວລາ string ດັ່ງທີ່ພວກເຮົາໄດ້ກວມເອົາແລ້ວ, ແຕ່ມັນອາດຈະເປັນ string ຈາກຄຸນລັກສະນະ href. ມັນຍັງສາມາດເປັນສະຕຣິງ:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
ແນ່ນອນ, ຕົວຢ່າງນີ້ຈະໃຫ້ພວກເຮົາກັບຄືນ array ຜົນໄດ້ຮັບເປັນ ["ໂລກ"]. ເພື່ອສະແດງໃຫ້ເຫັນການດໍາເນີນການນີ້, ຂ້າພະເຈົ້າໄດ້ສ້າງຫນ້າຕົວຢ່າງໂດຍໃຊ້ຫນ້າທີ່ຕໍ່ກັບສິ່ງທີ່ບໍ່ແມ່ນ DOM nodes: ເບິ່ງ Pen queryXPath [forked] ໂດຍ Bryan Rasmussen. ທ່ານຄວນສັງເກດລັກສະນະທີ່ຫນ້າປະຫລາດໃຈຂອງຫນ້າທີ່ແປພາສາ, ເຊິ່ງແມ່ນວ່າຖ້າທ່ານມີຕົວລະຄອນຢູ່ໃນການໂຕ້ຖຽງທີສອງ (i.e., ບັນຊີລາຍຊື່ຂອງຕົວອັກສອນທີ່ທ່ານຕ້ອງການແປ) ແລະບໍ່ມີຕົວອັກສອນທີ່ກົງກັນທີ່ຈະແປ, ຕົວອັກສອນນັ້ນຖືກໂຍກຍ້າຍອອກຈາກຜົນໄດ້ຮັບ. ດັ່ງນັ້ນ, ນີ້:
ແປຄຳອະທິບາຍກັບຄືນເປັນ ອັງກິດ (ສະຫະລັດ) ແປພາສາ ('ສະບາຍດີ, ຂ້ອຍຊື່ Inigo Montoya, ເຈົ້າຂ້າພໍ່ຂອງຂ້ອຍ, ກຽມຕາຍ','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…ຜົນໄດ້ຮັບໃນສະຕຣິງ, ລວມທັງຍະຫວ່າງ: [" * ** "]
ນີ້ຫມາຍຄວາມວ່າຕົວອັກສອນ "a" ກໍາລັງຖືກແປເປັນດາວ (*), ແຕ່ທຸກໆຕົວອັກສອນອື່ນໆທີ່ບໍ່ມີຄໍາແປທີ່ກໍານົດເປົ້າຫມາຍແມ່ນໄດ້ຖືກໂຍກຍ້າຍອອກຫມົດ. ຊ່ອງຫວ່າງແມ່ນທັງຫມົດທີ່ພວກເຮົາມີໄວ້ລະຫວ່າງຕົວອັກສອນ "a" ທີ່ແປ. ຫຼັງຈາກນັ້ນ, ອີກເທື່ອຫນຶ່ງ, ຄໍາຖາມນີ້:
ແປຄຳອະທິບາຍກັບຄືນເປັນ ອັງກິດ (ສະຫະລັດ) ແປພາສາ ('ສະບາຍດີ, ຂ້ອຍຊື່ Inigo Montoya, ເຈົ້າຂ້າພໍ່ຂອງຂ້ອຍ, ກຽມຕາຍ','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************)")
...ບໍ່ມີບັນຫາ ແລະໃຫ້ຜົນໄດ້ຮັບທີ່ມີລັກສະນະດັ່ງນີ້:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
ມັນອາດຈະເຮັດໃຫ້ທ່ານຕົກໃຈວ່າບໍ່ມີວິທີທີ່ງ່າຍໃນ JavaScript ທີ່ຈະເຮັດສິ່ງທີ່ຫນ້າທີ່ການແປພາສາ XPath ເຮັດ, ເຖິງແມ່ນວ່າສໍາລັບຫຼາຍໆກໍລະນີ, ແທນທີ່ທັງຫມົດດ້ວຍການສະແດງອອກປົກກະຕິສາມາດຈັດການກັບມັນໄດ້. ເຈົ້າສາມາດໃຊ້ວິທີດຽວກັນທີ່ຂ້ອຍໄດ້ສະແດງ, ແຕ່ມັນເປັນສິ່ງທີ່ດີທີ່ສຸດຖ້າເຈົ້າຕ້ອງການແປສາຍຕ່າງໆ. ຕົວຢ່າງຕໍ່ໄປນີ້ຫໍ່ຟັງຊັນການແປພາສາ XPath ເພື່ອສະຫນອງສະບັບ JavaScript ໄດ້: ເບິ່ງຟັງຊັນແປ Pen [forked] ໂດຍ Bryan Rasmussen. ເຈົ້າອາດຈະໃຊ້ບາງສິ່ງບາງຢ່າງແບບນີ້ຢູ່ໃສ? ພິຈາລະນາການເຂົ້າລະຫັດ Caesar Cipher ດ້ວຍການຊົດເຊີຍສາມບ່ອນ (ເຊັ່ນ: ການເຂົ້າລະຫັດເທິງສຸດຂອງສາຍຈາກ 48 B.C.):
ແປຄຳອະທິບາຍກັບຄືນເປັນ ອັງກິດ (ສະຫະລັດ) ແປພາສາ ("Caesar is plan to cross the 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!" ແນ່ນອນ, ຄົນເຮົາອາດມີການໃຊ້ parody ທຸກປະເພດຂອງຟັງຊັນນີ້. ຖ້ານັ້ນແມ່ນເຈົ້າ, ບົດຄວາມ TVTropes ນີ້ຄວນຈະໃຫ້ແຮງບັນດານໃຈແກ່ເຈົ້າ. ການນໍາໃຊ້ CSS ກັບ XPath ຈົ່ງຈື່ຈໍາເຫດຜົນຕົ້ນຕໍຂອງພວກເຮົາສໍາລັບການນໍາໃຊ້ຕົວເລືອກ CSS ຮ່ວມກັນກັບ XPath: CSS ເຂົ້າໃຈດີວ່າຊັ້ນແມ່ນຫຍັງ, ໃນຂະນະທີ່ສິ່ງທີ່ດີທີ່ສຸດທີ່ທ່ານສາມາດເຮັດໄດ້ກັບ XPath ແມ່ນການປຽບທຽບສະຕຣິງຂອງຄຸນລັກສະນະຂອງຊັ້ນ. ມັນຈະເຮັດວຽກໃນກໍລະນີຫຼາຍທີ່ສຸດ. ແຕ່ຖ້າທ່ານເຄີຍແລ່ນເຂົ້າໄປໃນສະຖານະການທີ່, ເວົ້າ, ຜູ້ໃດຜູ້ຫນຶ່ງສ້າງຫ້ອງຮຽນທີ່ມີຊື່ວ່າ .primaryLinks ແລະ .primaryLinks2 ແລະທ່ານໃຊ້ XPath ເພື່ອໃຫ້ໄດ້ຮັບຫ້ອງຮຽນ .primaryLinks, ຫຼັງຈາກນັ້ນທ່ານອາດຈະມີບັນຫາ. ຕາບໃດທີ່ບໍ່ມີຫຍັງໂງ່ຄືນັ້ນ, ທ່ານອາດຈະໃຊ້ XPath. ແຕ່ຂ້ອຍເສຍໃຈທີ່ລາຍງານວ່າຂ້ອຍໄດ້ເຮັດວຽກຢູ່ບ່ອນທີ່ຄົນເຮັດສິ່ງທີ່ໂງ່ໆເຫຼົ່ານັ້ນ. ນີ້ແມ່ນຕົວຢ່າງອື່ນທີ່ໃຊ້ CSS ແລະ XPath ຮ່ວມກັນ. ມັນສະແດງໃຫ້ເຫັນສິ່ງທີ່ເກີດຂື້ນໃນເວລາທີ່ພວກເຮົາໃຊ້ລະຫັດເພື່ອດໍາເນີນການ XPath ໃນ node context ທີ່ບໍ່ແມ່ນ node ຂອງເອກະສານ. ເບິ່ງ Pen css ແລະ xpath ຮ່ວມກັນ [forked] ໂດຍ Bryan Rasmussen. CSS query ແມ່ນ .relatedarticles a, ເຊິ່ງດຶງເອົາທັງສອງອົງປະກອບໃນ div ທີ່ຖືກມອບໝາຍໃຫ້ .relatedarticles class. ຫຼັງຈາກນັ້ນແມ່ນສາມຄໍາຖາມທີ່ "ບໍ່ດີ", ນັ້ນແມ່ນ, ຄໍາຖາມທີ່ບໍ່ໄດ້ເຮັດສິ່ງທີ່ພວກເຮົາຕ້ອງການໃຫ້ພວກເຂົາເຮັດໃນເວລາທີ່ແລ່ນກັບອົງປະກອບເຫຼົ່ານີ້ເປັນ context node. ຂ້ອຍສາມາດອະທິບາຍວ່າເປັນຫຍັງພວກມັນມີພຶດຕິກໍາທີ່ແຕກຕ່າງຈາກທີ່ເຈົ້າຄາດຫວັງ. ສາມຄໍາຖາມທີ່ບໍ່ດີຢູ່ໃນຄໍາຖາມແມ່ນ:
//text(): ສົ່ງຄືນຂໍ້ຄວາມທັງໝົດໃນເອກະສານ. //a/text(): ສົ່ງຄືນຂໍ້ຄວາມທັງໝົດພາຍໃນລິ້ງໃນເອກະສານ. ./a/text(): ບໍ່ມີຜົນຕອບແທນ.
ເຫດຜົນສໍາລັບຜົນໄດ້ຮັບເຫຼົ່ານີ້ແມ່ນວ່າໃນຂະນະທີ່ສະພາບການຂອງທ່ານແມ່ນອົງປະກອບທີ່ສົ່ງຄືນຈາກການສອບຖາມ CSS, // ກົງກັນຂ້າມກັບເອກະສານທັງຫມົດ. ນີ້ແມ່ນຄວາມເຂັ້ມແຂງຂອງ XPath; CSS ບໍ່ສາມາດໄປຈາກຂໍ້ຂຶ້ນໄປເຖິງບັນພະບຸລຸດແລະຫຼັງຈາກນັ້ນກັບອ້າຍນ້ອງຂອງບັນພະບຸລຸດນັ້ນ, ແລະຍ່າງລົງໄປທີ່ລູກຫລານຂອງອ້າຍນ້ອງນັ້ນ. ແຕ່ XPath ສາມາດເຮັດໄດ້. ໃນຂະນະດຽວກັນ, ./ ສອບຖາມເດັກນ້ອຍຂອງ node ປະຈຸບັນ, ບ່ອນທີ່ dot (.) ເປັນຕົວແທນຂອງ node ປະຈຸບັນ, ແລະ forward slash (/) ເປັນຕົວແທນໄປຫາບາງ node ເດັກນ້ອຍ — ບໍ່ວ່າຈະເປັນຄຸນລັກສະນະ, ອົງປະກອບຫຼືຂໍ້ຄວາມແມ່ນຖືກກໍານົດໂດຍພາກສ່ວນຕໍ່ໄປຂອງເສັ້ນທາງ. ແຕ່ບໍ່ມີອົງປະກອບຂອງເດັກນ້ອຍທີ່ເລືອກໂດຍການສອບຖາມ CSS, ດັ່ງນັ້ນການສອບຖາມນັ້ນບໍ່ໄດ້ຜົນຫຍັງ. ມີສາມຄໍາຖາມທີ່ດີຢູ່ໃນຕົວຢ່າງສຸດທ້າຍນັ້ນ:
.//text(), ./text(), normalize-space (./text()).
ການສອບຖາມແບບ normalize-space ສະແດງໃຫ້ເຫັນເຖິງການໃຊ້ຟັງຊັນ XPath, ແຕ່ຍັງແກ້ໄຂບັນຫາທີ່ລວມຢູ່ໃນຄໍາຖາມອື່ນໆ. HTML ມີໂຄງສ້າງດັ່ງນີ້:
ອັດຕະໂນມັດການທົດສອບຄຸນນະສົມບັດຂອງທ່ານກັບ Selenium WebDriver
ຄິວຣີສົ່ງຄືນຟີດເສັ້ນຢູ່ຈຸດເລີ່ມຕົ້ນ ແລະຈຸດສິ້ນສຸດຂອງຂໍ້ຄວາມ,ແລະ normalize-space ເອົາສິ່ງນີ້ອອກ. ການໃຊ້ຟັງຊັນ XPath ໃດໆກໍຕາມທີ່ສົ່ງຄືນອັນອື່ນທີ່ບໍ່ແມ່ນ boolean ດ້ວຍການປ້ອນ XPath ໃຊ້ກັບຟັງຊັນອື່ນໆ. ການສາທິດຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນຕົວຢ່າງຈໍານວນຫນຶ່ງ: ເບິ່ງຕົວຢ່າງຟັງຊັນ Pen xpath [forked] ໂດຍ Bryan Rasmussen. ຕົວຢ່າງທໍາອິດສະແດງໃຫ້ເຫັນບັນຫາທີ່ທ່ານຄວນລະວັງ. ໂດຍສະເພາະ, ລະຫັດຕໍ່ໄປນີ້:
document.queryXPaths("substring-after(//a/@href,'https://')");
…ສົ່ງຄືນໜຶ່ງສະຕຣິງ:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກ, ບໍ່ແມ່ນບໍ? ຟັງຊັນເຫຼົ່ານີ້ບໍ່ສົ່ງຄືນ arrays ແຕ່ເປັນສະຕຣິງດຽວຫຼືຕົວເລກດຽວ. ການເຮັດວຽກຂອງຟັງຊັນຢູ່ທຸກບ່ອນທີ່ມີຜົນໄດ້ຮັບຫຼາຍຜົນພຽງແຕ່ຜົນໄດ້ຮັບທໍາອິດ. ຜົນໄດ້ຮັບທີສອງສະແດງໃຫ້ເຫັນສິ່ງທີ່ພວກເຮົາຕ້ອງການແທ້ໆ:
document.queryCSSSelectors("a").queryXPaths("substring-after./@href,'https://')");
ເຊິ່ງສົ່ງຄືນ array ຂອງສອງສະຕຣິງ:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
ຟັງຊັນ XPath ສາມາດຖືກວາງໄວ້ຄືກັບຟັງຊັນໃນ JavaScript. ດັ່ງນັ້ນ, ຖ້າພວກເຮົາຮູ້ໂຄງສ້າງ URL ຂອງ Smashing Magazine, ພວກເຮົາສາມາດເຮັດໄດ້ດັ່ງຕໍ່ໄປນີ້ (ການນໍາໃຊ້ຕົວຫນັງສືແມ່ແບບແມ່ນແນະນໍາ): `ແປ( ສາຍຍ່ອຍ( substring-after./@href, 'www.smashingmagazine.com/') ,9), '/','')`
ນີ້ແມ່ນການສັບສົນເລັກນ້ອຍໃນຂອບເຂດທີ່ມັນຕ້ອງການຄໍາຄິດຄໍາເຫັນທີ່ອະທິບາຍວ່າມັນເຮັດ: ເອົາ URL ທັງຫມົດຈາກ href attribute ຫຼັງຈາກ www.smashingmagazine.com/, ເອົາຕົວອັກສອນເກົ້າຕົວທໍາອິດ, ຫຼັງຈາກນັ້ນແປຕົວຫຍໍ້ຫນ້າ (/) ທີ່ບໍ່ມີປະໂຫຍດເພື່ອກໍາຈັດການສິ້ນສຸດຂອງ slash. array ຜົນໄດ້ຮັບ:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
ກໍລະນີການນໍາໃຊ້ XPath ເພີ່ມເຕີມ XPath ສາມາດສ່ອງແສງໃນການທົດສອບຢ່າງແທ້ຈິງ. ເຫດຜົນບໍ່ແມ່ນເລື່ອງຍາກທີ່ຈະເຫັນ, ຍ້ອນວ່າ XPath ສາມາດຖືກນໍາໃຊ້ເພື່ອເອົາທຸກໆອົງປະກອບໃນ DOM, ຈາກຕໍາແຫນ່ງໃດໆໃນ DOM, ໃນຂະນະທີ່ CSS ບໍ່ສາມາດ. ທ່ານບໍ່ສາມາດນັບຢູ່ໃນຫ້ອງຮຽນ CSS ທີ່ຄົງຄ້າງຢູ່ໃນລະບົບການກໍ່ສ້າງທີ່ທັນສະໄຫມຫຼາຍ, ແຕ່ດ້ວຍ XPath, ພວກເຮົາສາມາດເຮັດໃຫ້ກົງກັນທີ່ເຂັ້ມແຂງກ່ຽວກັບເນື້ອໃນຂໍ້ຄວາມຂອງອົງປະກອບໃດຫນຶ່ງ, ໂດຍບໍ່ຄໍານຶງເຖິງໂຄງສ້າງ DOM ທີ່ມີການປ່ຽນແປງ. ມີການຄົ້ນຄວ້າກ່ຽວກັບເຕັກນິກທີ່ອະນຸຍາດໃຫ້ທ່ານເຮັດການທົດສອບ XPath ທົນທານ. ບໍ່ມີຫຍັງຮ້າຍແຮງໄປກວ່າການທົດສອບ flake ອອກແລະລົ້ມເຫລວພຽງແຕ່ເນື່ອງຈາກວ່າຕົວເລືອກ 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 ຖືກຍົກເລີກ. ມີການສົນທະນາທັງໝົດທີ່ເກີດຂຶ້ນຢູ່ຂ່າວແຮກເກີທີ່ເຕັມໄປດ້ວຍການໂຕ້ຖຽງກັນຕໍ່ການປະຕິເສດ. ຕອບຕົວມັນເອງເປັນຕົວຢ່າງທີ່ດີຂອງການສ້າງກອບ blogging ກັບ 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 ຈະເປັນວິທີການທີ່ເຫມາະສົມ. ຜູ້ຂາຍຕົວທ່ອງເວັບ, ໂດຍທໍາມະຊາດທີ່ພວກເຂົາສ້າງຕົວທ່ອງເວັບ, ສາມາດເຂົ້າຫາການເຊື່ອມໂຍງໃນລະດັບທີ່ເລິກເຊິ່ງກວ່າທີ່ພວກເຮົາສາມາດ "ຈາກພາຍນອກ".— Norm Tovey-Walsh
ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າຄໍາຄິດເຫັນຂອງ Tovey-Walsh ໄດ້ມາປະມານຫນຶ່ງອາທິດກ່ອນການປະກາດການປະຕິເສດ XSLT. ສະຫຼຸບ ຂ້ອຍສາມາດສືບຕໍ່ແລະຕໍ່ໄປ. ແຕ່ຂ້ອຍຫວັງວ່າສິ່ງນີ້ໄດ້ສະແດງໃຫ້ເຫັນເຖິງພະລັງຂອງ XPath ແລະໃຫ້ເຈົ້າຕົວຢ່າງຫຼາຍຢ່າງທີ່ສະແດງໃຫ້ເຫັນວິທີການໃຊ້ມັນເພື່ອບັນລຸສິ່ງທີ່ຍິ່ງໃຫຍ່. ມັນເປັນຕົວຢ່າງທີ່ສົມບູນແບບຂອງເທກໂນໂລຍີເກົ່າແກ່ໃນ stack ຂອງຕົວທ່ອງເວັບທີ່ຍັງມີຜົນປະໂຫຍດຫຼາຍໃນມື້ນີ້, ເຖິງແມ່ນວ່າທ່ານບໍ່ເຄີຍຮູ້ວ່າມັນມີຢູ່ຫຼືບໍ່ເຄີຍພິຈາລະນາເຖິງມັນ. ອ່ານເພີ່ມເຕີມ
"ການເພີ່ມຄວາມຢືດຢຸ່ນຂອງການທົດສອບເວັບອັດຕະໂນມັດດ້ວຍພາສາທໍາມະຊາດ" (ACM Digital Library) ໂດຍ Maroun Ayli, Youssef Bakouny, Nader Jalloul, ແລະ Rima Kilany ບົດຄວາມນີ້ໃຫ້ຕົວຢ່າງ XPath ຈໍານວນຫຼາຍສໍາລັບການຂຽນການທົດສອບຄວາມທົນທານ. XPath (MDN)ນີ້ເປັນບ່ອນທີ່ດີເລີດທີ່ຈະເລີ່ມຕົ້ນຖ້າຫາກວ່າທ່ານຕ້ອງການຄໍາອະທິບາຍດ້ານວິຊາການລາຍລະອຽດວິທີການ XPath ເຮັດວຽກ. XPath Tutorial (ZVON)ຂ້ອຍພົບວ່າການສອນນີ້ເປັນປະໂຫຍດທີ່ສຸດໃນການຮຽນຮູ້ຂອງຂ້ອຍເອງ, ຂອບໃຈຫຼາຍໆຕົວຢ່າງ ແລະຄໍາອະທິບາຍທີ່ຊັດເຈນ. XPather ເຄື່ອງມືໂຕ້ຕອບນີ້ຊ່ວຍໃຫ້ທ່ານເຮັດວຽກໂດຍກົງກັບລະຫັດ.
