ฉันอยู่ในการพัฒนาส่วนหน้ามานานพอที่จะเห็นแนวโน้มในช่วงหลายปีที่ผ่านมา: นักพัฒนารุ่นเยาว์ที่ทำงานกับกระบวนทัศน์ใหม่ของการเขียนโปรแกรมโดยไม่เข้าใจบริบททางประวัติศาสตร์ของมัน แน่นอนว่าการไม่รู้อะไรบางอย่างเป็นเรื่องที่เข้าใจได้อย่างสมบูรณ์แบบ เว็บเป็นสถานที่ที่ใหญ่มากพร้อมด้วยทักษะและความชำนาญพิเศษที่หลากหลาย และเราก็ไม่รู้เสมอไปว่าเราไม่รู้อะไร การเรียนรู้ในสาขานี้เป็นการเดินทางต่อเนื่องมากกว่าสิ่งที่เกิดขึ้นครั้งเดียวและจบลง กรณีตัวอย่าง: มีคนในทีมของฉันถามว่าเป็นไปได้หรือไม่ที่จะบอกได้ว่าผู้ใช้ออกจากแท็บใดแท็บหนึ่งใน UI หรือไม่ ฉันชี้ให้เห็นเหตุการณ์ beforeunload ของ JavaScript แต่ผู้ที่แก้ไขปัญหานี้มาก่อนจะรู้ว่าสิ่งนี้เป็นไปได้ เพราะพวกเขาได้รับการแจ้งเตือนเกี่ยวกับข้อมูลที่ยังไม่ได้บันทึกบนไซต์อื่น ซึ่งเป็นเรื่องปกติสำหรับการดาวน์โหลดก่อนยกเลิกการโหลด ฉันยังชี้ให้เห็นหน้าซ่อนและการมองเห็นเปลี่ยนเหตุการณ์ให้เพื่อนร่วมงานของฉันทราบเพื่อการวัดผลที่ดี ฉันรู้เรื่องนี้ได้อย่างไร? เพราะมันเกิดขึ้นในโปรเจ็กต์อื่น ไม่ใช่เพราะฉันศึกษามันเมื่อเริ่มเรียนรู้ JavaScript ความจริงก็คือเฟรมเวิร์กส่วนหน้าที่ทันสมัยกำลังยืนอยู่บนไหล่ของยักษ์ใหญ่ด้านเทคโนโลยีที่อยู่ก่อนหน้าพวกเขา พวกเขาเป็นนามธรรมแนวทางปฏิบัติในการพัฒนา บ่อยครั้งเพื่อประสบการณ์นักพัฒนาที่ดีขึ้น ซึ่งจะลดหรือขจัดความจำเป็นในการรู้หรือสัมผัสสิ่งที่เป็นแนวคิดส่วนหน้าที่สำคัญซึ่งทุกคนอาจควรรู้ พิจารณา CSS Object Model (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 โดยเฉลี่ยมีความยาวไม่เกิน 5,000 คำ ฉันอยู่ที่มากกว่านั้นแล้ว2,000 คำโดยพื้นฐานเพียงครึ่งเดียวเท่านั้น ดังนั้น ฉันจะเริ่มทำสิ่งดีๆ กับ XPath และให้ลิงก์บางส่วนที่คุณสามารถใช้สำหรับพื้นฐานได้ หากคุณพบว่าสิ่งนี้น่าสนใจ การรวม XPath และ CSS XPath สามารถทำสิ่งต่างๆ มากมายที่ตัวเลือก CSS ไม่สามารถทำได้เมื่อทำการสืบค้นองค์ประกอบ แต่ตัวเลือก CSS ยังสามารถทำบางสิ่งที่ XPath ไม่สามารถทำได้ กล่าวคือ ค้นหาองค์ประกอบตามชื่อคลาส
ซีเอสเอส XPath .myClass /*[มี(@คลาส, "myClass")]
ในตัวอย่างนี้ องค์ประกอบแบบสอบถาม CSS ที่มีชื่อคลาส .myClass ในขณะเดียวกัน ตัวอย่าง XPath จะสอบถามองค์ประกอบที่มีคลาสแอตทริบิวต์ที่มีสตริง “myClass” กล่าวอีกนัยหนึ่ง จะเลือกองค์ประกอบที่มี myClass ในคุณลักษณะใดๆ รวมถึงองค์ประกอบที่มีชื่อคลาส .myClass — เช่นเดียวกับองค์ประกอบที่มี “myClass” ในสตริง เช่น .myClass2 XPath นั้นกว้างกว่าในแง่นั้น ดังนั้นไม่ ฉันไม่ได้แนะนำว่าเราควรละทิ้ง CSS และเริ่มเลือกองค์ประกอบทั้งหมดผ่าน XPath นั่นไม่ใช่ประเด็น ประเด็นก็คือ XPath สามารถทำสิ่งที่ CSS ไม่สามารถทำได้และยังคงมีประโยชน์มาก แม้ว่าจะเป็นเทคโนโลยีเก่าในเบราว์เซอร์สแต็กและอาจดูไม่ชัดเจนตั้งแต่แรกเห็น มาใช้เทคโนโลยีทั้งสองร่วมกันไม่เพียงเพราะเราทำได้ แต่เพราะเราจะเรียนรู้บางอย่างเกี่ยวกับ XPath ในกระบวนการนี้ ทำให้มันเป็นอีกเครื่องมือหนึ่งในสแต็กของคุณ — สิ่งหนึ่งที่คุณอาจไม่รู้ว่ามีมาตลอด! ปัญหาคือวิธีการ document.evaluate ของ JavaScript และวิธีการเลือกคิวรีต่างๆ ที่เราใช้กับ CSS API สำหรับ JavaScript นั้นเข้ากันไม่ได้ ฉันได้สร้าง API การสืบค้นที่เข้ากันได้เพื่อเริ่มต้นใช้งาน แม้ว่าเป็นที่ยอมรับ ฉันไม่ได้คิดอะไรมากเพราะมันแตกต่างจากสิ่งที่เรากำลังทำอยู่ที่นี่ นี่เป็นตัวอย่างการทำงานที่ค่อนข้างง่ายของตัวสร้างแบบสอบถามแบบใช้ซ้ำได้: ดู Pen queryXPath [แยก] โดย Bryan Rasmussen ฉันได้เพิ่มสองวิธีในวัตถุเอกสาร: queryCSSSelectors (ซึ่งโดยพื้นฐานแล้วคือ querySelectorAll) และ queryXPaths ทั้งสองสิ่งนี้ส่งคืนวัตถุ queryResults:
{ ประเภทแบบสอบถาม: โหนด | สตริง | หมายเลข | บูลีน, ผลลัพธ์: องค์ประกอบใด ๆ[] // html, องค์ประกอบ xml, สตริง, ตัวเลข, บูลีน, queryCSSSelectors: (แบบสอบถาม: สตริง แก้ไข: บูลีน) => queryResults, queryXpaths: (แบบสอบถาม: สตริง แก้ไข: บูลีน) => queryResults }
ฟังก์ชัน queryCSSSelectors และ queryXpaths จะเรียกใช้แบบสอบถามที่คุณกำหนดไว้เหนือองค์ประกอบในอาร์เรย์ผลลัพธ์ ตราบใดที่อาร์เรย์ผลลัพธ์นั้นเป็นประเภทโหนดแน่นอน มิฉะนั้นจะส่งคืน queryResult พร้อมอาร์เรย์ว่างและประเภทของโหนด หากคุณสมบัติการแก้ไขถูกตั้งค่าเป็นจริง ฟังก์ชันจะเปลี่ยนผลลัพธ์การสืบค้นของตนเอง ไม่ควรใช้สิ่งนี้ในสภาพแวดล้อมการผลิต ฉันกำลังทำเช่นนี้เพียงเพื่อแสดงเอฟเฟกต์ต่างๆ ของการใช้ API การค้นหาทั้งสองร่วมกัน ตัวอย่างแบบสอบถาม ฉันต้องการแสดงตัวอย่างเล็กๆ น้อยๆ ของแบบสอบถาม XPath ต่างๆ ที่แสดงให้เห็นถึงประสิทธิภาพบางอย่างที่พวกเขาสามารถทำได้ และวิธีการใช้แบบสอบถามเหล่านั้นแทนแนวทางอื่นๆ ตัวอย่างแรกคือ //li/text() คำสั่งนี้จะสอบถามองค์ประกอบ li ทั้งหมดและส่งกลับโหนดข้อความ ดังนั้น หากเราต้องสืบค้น HTML ต่อไปนี้:
- หนึ่ง
- สอง
- สาม
…นี่คือสิ่งที่ส่งคืน:
{"queryType":"xpathEvaluate", "ผลลัพธ์":["one", "two", "three"],"resultType": "string"}
กล่าวอีกนัยหนึ่ง เราได้รับอาร์เรย์ต่อไปนี้: ["หนึ่ง", "สอง", "สาม"] โดยปกติ คุณจะต้องค้นหาองค์ประกอบ li เพื่อให้ได้สิ่งนั้น เปลี่ยนผลลัพธ์ของการสืบค้นนั้นเป็นอาร์เรย์ แมปอาร์เรย์ และส่งคืนโหนดข้อความของแต่ละองค์ประกอบ แต่เราสามารถทำได้อย่างกระชับยิ่งขึ้นด้วย XPath: document.queryXPaths("//li/text()").ผลลัพธ์
โปรดสังเกตว่าวิธีรับโหนดข้อความคือการใช้ text() ซึ่งดูเหมือนลายเซ็นของฟังก์ชัน — และมันก็เป็นเช่นนั้น มันจะส่งกลับโหนดข้อความขององค์ประกอบ ในตัวอย่างของเรา มีองค์ประกอบ li สามรายการในมาร์กอัป โดยแต่ละองค์ประกอบประกอบด้วยข้อความ ("หนึ่ง" "สอง" และ "สาม")
ลองดูอีกตัวอย่างหนึ่งของข้อความค้นหา () สมมติว่านี่คือมาร์กอัปของเรา:
มาเขียนแบบสอบถามที่ส่งคืนค่าแอตทริบิวต์ href: document.queryXPaths("//a[text() = 'ลงชื่อเข้าใช้']/@href").results
นี่คือแบบสอบถาม XPath ในเอกสารปัจจุบัน เช่นเดียวกับตัวอย่างสุดท้าย แต่คราวนี้เราจะส่งคืนแอตทริบิวต์ href ของลิงก์ (องค์ประกอบ) ที่มีข้อความ "ลงชื่อเข้าใช้" ได้คืนจริงผลลัพธ์คือ ["/login.html"] ภาพรวมฟังก์ชัน XPath มีฟังก์ชัน XPath อยู่จำนวนหนึ่ง และคุณอาจไม่คุ้นเคยกับฟังก์ชันเหล่านี้ ฉันคิดว่ามีหลายอย่างที่ควรค่าแก่การรู้ รวมถึงสิ่งต่อไปนี้:
starts-withIf ข้อความขึ้นต้นด้วยตัวอย่างข้อความอื่นที่เจาะจง start-with(@href, 'http:') จะคืนค่าเป็นจริงหากแอตทริบิวต์ href ขึ้นต้นด้วย http: containsIf ข้อความมีตัวอย่างข้อความอื่นที่เจาะจง, contains(text(), "Smashing Magazine") จะคืนค่าเป็นจริงหากโหนดข้อความมีคำว่า "Smashing Magazine" อยู่ในนั้นทุกที่ countส่งคืนการนับจำนวนรายการที่ตรงกันในการสืบค้น ตัวอย่างเช่น count(//*[starts-with(@href, 'http:']) ส่งคืนจำนวนลิงก์ในโหนดบริบทที่มีองค์ประกอบที่มีแอตทริบิวต์ href ซึ่งมีข้อความที่ขึ้นต้นด้วย http: substringทำงานเหมือนสตริงย่อย JavaScript ยกเว้นว่าคุณส่งสตริงเป็นอาร์กิวเมนต์ ตัวอย่างเช่น substring("my text", 2, 4) ส่งคืน "y t" substring-beforeReturns ส่วนของสตริงก่อนสตริงอื่น ตัวอย่างเช่น substing-before("my text", " ") ส่งคืน "my" ในทำนองเดียวกัน substring-before("hi","bye") จะส่งกลับสตริงว่าง substring-afterส่งคืนส่วนของสตริงหลังสตริงอื่น ตัวอย่างเช่น substing-after("my text", " ") ส่งคืน "text" ในทำนองเดียวกัน substring-after("hi","bye") ส่งคืนสตริงว่าง Normalize-spaceส่งคืนสตริงอาร์กิวเมนต์ด้วยช่องว่างที่ทำให้เป็นมาตรฐานโดยการตัดช่องว่างนำหน้าและต่อท้ายและแทนที่ลำดับของอักขระช่องว่างด้วยช่องว่างเดียว notส่งคืนบูลีนจริงหากอาร์กิวเมนต์เป็นเท็จ มิฉะนั้นจะเป็นเท็จ trueReturns บูลีนจริง falseReturns บูลีนเท็จ concat เช่นเดียวกับ JavaScript concat ยกเว้นว่าคุณไม่ได้เรียกใช้มันเป็นวิธีการบนสตริง แต่คุณใส่สตริงทั้งหมดที่คุณต้องการต่อเข้าด้วยกันแทน string-lengthThis ไม่เหมือนกับ JavaScript string-length แต่จะส่งคืนความยาวของสตริงที่กำหนดเป็นอาร์กิวเมนต์ TranslateThis รับสตริงและเปลี่ยนอาร์กิวเมนต์ที่สองเป็นอาร์กิวเมนต์ที่สาม ตัวอย่างเช่น แปล ("abcdef", "abc", "XYZ") เอาต์พุต XYZdef
นอกเหนือจากฟังก์ชัน XPath เหล่านี้แล้ว ยังมีฟังก์ชันอื่นๆ อีกจำนวนหนึ่งที่ทำงานเหมือนกับฟังก์ชัน JavaScript หรือเทียบเท่าในภาษาการเขียนโปรแกรมใดๆ ก็ตาม ซึ่งคุณอาจพบว่ามีประโยชน์เช่นกัน เช่น พื้น เพดาน กลม ผลรวม และอื่นๆ การสาธิตต่อไปนี้จะอธิบายแต่ละฟังก์ชันเหล่านี้: ดูฟังก์ชันตัวเลข Pen XPath [แยก] โดย Bryan Rasmussen โปรดทราบว่า เช่นเดียวกับฟังก์ชันการจัดการสตริงส่วนใหญ่ ฟังก์ชันตัวเลขจำนวนมากรับอินพุตเดียว แน่นอนว่านี่เป็นเพราะว่าควรใช้สำหรับการสืบค้น ดังตัวอย่าง XPath ที่ผ่านมา: //li[ชั้น(ข้อความ()) > 250]/@val
หากคุณใช้มัน ดังตัวอย่างส่วนใหญ่ คุณจะจบลงด้วยการรันมันบนโหนดแรกที่ตรงกับเส้นทาง นอกจากนี้ยังมีฟังก์ชันการแปลงประเภทบางประเภทที่คุณควรหลีกเลี่ยง เนื่องจาก JavaScript มีปัญหาในการแปลงประเภทเป็นของตัวเองอยู่แล้ว แต่อาจมีบางครั้งที่คุณต้องการแปลงสตริงเป็นตัวเลขเพื่อตรวจสอบกับตัวเลขอื่น ฟังก์ชั่นที่กำหนดประเภทของบางสิ่ง ได้แก่ บูลีน ตัวเลข สตริง และโหนด เหล่านี้เป็นประเภทข้อมูล XPath ที่สำคัญ และอย่างที่คุณอาจจินตนาการได้ ฟังก์ชันเหล่านี้ส่วนใหญ่สามารถใช้ได้กับประเภทข้อมูลที่ไม่ใช่โหนด DOM ตัวอย่างเช่น substring-after รับสตริงตามที่เราได้อธิบายไปแล้ว แต่อาจเป็นสตริงจากแอตทริบิวต์ href นอกจากนี้ยังสามารถเป็นเพียงแค่สตริง:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
แน่นอนว่าตัวอย่างนี้จะคืนค่าอาร์เรย์ผลลัพธ์เป็น ["world"] เพื่อแสดงสิ่งนี้จริง ฉันได้สร้างหน้าสาธิตโดยใช้ฟังก์ชันกับสิ่งที่ไม่ใช่โหนด DOM: ดู Pen queryXPath [แยก] โดย Bryan Rasmussen คุณควรสังเกตแง่มุมที่น่าประหลาดใจของฟังก์ชันการแปล ซึ่งก็คือถ้าคุณมีอักขระในอาร์กิวเมนต์ที่สอง (เช่น รายการอักขระที่คุณต้องการแปล) และไม่มีอักขระที่ตรงกันที่จะแปล อักขระนั้นจะถูกลบออกจากเอาต์พุต ดังนั้นสิ่งนี้:
แปล('สวัสดี ฉันชื่ออินิโก มอนโตยา คุณฆ่าพ่อของฉัน เตรียมตัวตาย','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…ผลลัพธ์เป็นสตริง รวมทั้งช่องว่าง: [" * * ** "]
ซึ่งหมายความว่าตัวอักษร "a" กำลังถูกแปลเป็นเครื่องหมายดอกจัน (*) แต่อักขระอื่นๆ ที่ไม่มีคำแปลตามสตริงเป้าหมายจะถูกลบออกทั้งหมด ช่องว่างคือสิ่งเดียวที่เราเหลืออยู่ระหว่างอักขระ "a" ที่แปลแล้ว อีกครั้งคำถามนี้:
แปล('สวัสดี ฉันชื่ออินิโก มอนโตยา คุณฆ่าพ่อของฉัน เตรียมตัวตาย','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")
…ไม่มีปัญหาและให้ผลลัพธ์ที่มีลักษณะดังนี้:
"**** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
คุณอาจพบว่าไม่มีวิธีที่ง่ายใน JavaScript ที่จะทำเหมือนกับที่ฟังก์ชันแปล XPath ทำ แม้ว่าในหลายกรณีการใช้งาน การแทนที่ทั้งหมดด้วยนิพจน์ทั่วไปสามารถจัดการได้ คุณสามารถใช้วิธีการเดียวกันกับที่ฉันสาธิตไปแล้ว แต่นั่นเป็นวิธีที่ไม่ดีนักหากสิ่งที่คุณต้องการคือการแปลสตริง การสาธิตต่อไปนี้รวมฟังก์ชันการแปลของ XPath เพื่อให้มีเวอร์ชัน JavaScript: ดูฟังก์ชันการแปลด้วยปากกา [แยก] โดย Bryan Rasmussen คุณสามารถใช้อะไรเช่นนี้ได้ที่ไหน? พิจารณาการเข้ารหัส Caesar Cipher ด้วยออฟเซ็ตสามตำแหน่ง (เช่น การเข้ารหัสระดับบนสุดจาก 48 ปีก่อนคริสตกาล):
แปล ("ซีซาร์กำลังวางแผนที่จะข้ามรูบิคอน!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
ข้อความที่ป้อน "ซีซาร์กำลังวางแผนที่จะข้ามรูบิคอน!" ผลลัพธ์ใน “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” เพื่อให้เป็นตัวอย่างสั้นๆ ของความเป็นไปได้ต่างๆ ฉันได้สร้างฟังก์ชันโลหะที่รับอินพุตสตริงและใช้ฟังก์ชันแปลเพื่อส่งคืนข้อความ รวมถึงอักขระทุกตัวที่ใช้เครื่องหมายอัศเจรีย์ ดูฟังก์ชั่นโลหะปากกา [แยกออก] โดย Bryan Rasmussen
โลหะ const = (str) => { กลับแปล (str, "AOUaou", "ÅÖÜäöü"); }
และหากได้รับข้อความว่า "Motley Crue กฎ ร็อคกับเป็ด!" จะส่งกลับ "Mötley Crüe rüles, röck ön dudes!" แน่นอนว่าอาจมีการใช้ฟังก์ชันนี้ล้อเลียนทุกประเภท หากเป็นคุณ บทความ TVTropes นี้น่าจะให้แรงบันดาลใจมากมายแก่คุณ การใช้ CSS กับ XPath จำเหตุผลหลักของเราในการใช้ตัวเลือก CSS ร่วมกับ XPath: CSS ค่อนข้างเข้าใจดีว่าคลาสคืออะไร ในขณะที่สิ่งที่ดีที่สุดที่คุณสามารถทำได้กับ XPath คือการเปรียบเทียบสตริงของแอตทริบิวต์ class ซึ่งจะได้ผลในกรณีส่วนใหญ่ แต่ถ้าคุณเคยพบเจอสถานการณ์ที่มีคนสร้างคลาสชื่อ .primaryLinks และ .primaryLinks2 และคุณใช้ XPath เพื่อรับคลาส .primaryLinks คุณก็อาจจะประสบปัญหา ตราบใดที่ไม่มีอะไรไร้สาระแบบนั้น คุณก็คงจะใช้ XPath แต่ฉันเสียใจที่ต้องรายงานว่าฉันได้ทำงานในสถานที่ที่ผู้คนทำสิ่งไร้สาระเหล่านั้น นี่คือการสาธิตอื่นที่ใช้ CSS และ XPath ร่วมกัน มันแสดงสิ่งที่เกิดขึ้นเมื่อเราใช้โค้ดเพื่อเรียกใช้ XPath บนโหนดบริบทที่ไม่ใช่โหนดของเอกสาร ดู Pen css และ xpath ร่วมกัน [แยก] โดย Bryan Rasmussen แบบสอบถาม CSS คือ . relatedarticles a ซึ่งดึงองค์ประกอบ a สองรายการใน div ที่กำหนดคลาส . relatedarticles หลังจากนั้นจะมีข้อความค้นหาที่ “ไม่ดี” สามรายการ กล่าวคือ ข้อความค้นหาที่ไม่ได้ทำในสิ่งที่เราต้องการให้พวกเขาทำเมื่อทำงานโดยมีองค์ประกอบเหล่านี้เป็นโหนดบริบท ฉันสามารถอธิบายได้ว่าทำไมพวกเขาถึงมีพฤติกรรมแตกต่างจากที่คุณคาดหวัง คำถามที่ไม่ถูกต้องสามข้อที่เป็นปัญหาคือ:
//text(): ส่งคืนข้อความทั้งหมดในเอกสาร //a/text(): ส่งคืนข้อความทั้งหมดภายในลิงก์ในเอกสาร ./a/text(): ไม่ส่งคืนผลลัพธ์
สาเหตุของผลลัพธ์เหล่านี้ก็คือ แม้ว่าบริบทของคุณจะเป็นองค์ประกอบที่ส่งคืนจากการสืบค้น CSS แต่ // กลับขัดแย้งกับทั้งเอกสาร นี่คือจุดแข็งของ XPath CSS ไม่สามารถเดินทางจากโหนดไปยังบรรพบุรุษแล้วไปยังพี่น้องของบรรพบุรุษนั้น และเดินลงไปยังลูกหลานของพี่น้องนั้น แต่ XPath สามารถทำได้ ในขณะเดียวกัน ./ จะสอบถามลูกของโหนดปัจจุบัน โดยที่จุด (.) แสดงถึงโหนดปัจจุบัน และเครื่องหมายทับ (/) แสดงถึงการไปยังโหนดย่อยบางโหนด ไม่ว่าจะเป็นคุณลักษณะ องค์ประกอบ หรือข้อความจะถูกกำหนดโดยส่วนถัดไปของเส้นทาง แต่ไม่มีองค์ประกอบย่อยที่เลือกโดยแบบสอบถาม CSS ดังนั้นแบบสอบถามนั้นจึงไม่ส่งคืนอะไรเลย มีคำถามที่ดีสามข้อในการสาธิตครั้งล่าสุด:
.//ข้อความ(), ./ข้อความ() ปรับพื้นที่ให้เป็นปกติ (./text())
แบบสอบถาม Normalize-space สาธิตการใช้ฟังก์ชัน XPath แต่ยังแก้ไขปัญหาที่รวมอยู่ในแบบสอบถามอื่นๆ ด้วย HTML มีโครงสร้างดังนี้:
ทำการทดสอบคุณสมบัติของคุณโดยอัตโนมัติด้วย Selenium WebDriver
แบบสอบถามส่งคืนการป้อนบรรทัดที่จุดเริ่มต้นและจุดสิ้นสุดของโหนดข้อความและ Normalize-space จะลบสิ่งนี้ การใช้ฟังก์ชัน XPath ใดๆ ที่ส่งคืนค่าอื่นที่ไม่ใช่บูลีนพร้อมกับอินพุต XPath จะนำไปใช้กับฟังก์ชันอื่นๆ การสาธิตต่อไปนี้แสดงตัวอย่างจำนวนหนึ่ง: ดูตัวอย่างฟังก์ชัน Pen xpath [แยก] โดย 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 Magazine เราก็สามารถทำสิ่งต่อไปนี้ได้ (แนะนำให้ใช้เทมเพลตตามตัวอักษร): `แปล( สตริงย่อย( สตริงย่อยหลัง (./@href, 'www.smashingmagazine.com/') ,9) '/','')`
สิ่งนี้เริ่มซับซ้อนเกินไปเล็กน้อยจนจำเป็นต้องมีความคิดเห็นเพื่ออธิบายว่ามันทำอะไร: นำ URL ทั้งหมดจากแอตทริบิวต์ href ที่อยู่หลัง www.smashingmagazine.com/ ลบอักขระเก้าตัวแรกออก จากนั้นแปลอักขระเครื่องหมายทับ (/) เป็นศูนย์เพื่อกำจัดเครื่องหมายทับที่สิ้นสุด อาร์เรย์ผลลัพธ์:
["การทดสอบคุณสมบัติซีลีเนียม-webdriver", "ผลการทดสอบอัตโนมัติ - ปรับปรุงการเข้าถึง"]
กรณีการใช้งาน 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[1] /img[@data-testID='leader'] ] /h2/ ข้อความ() `);
มาดูการสาธิตเพื่อดูว่าทั้งหมดมารวมกันได้อย่างไร: ดูแบบสอบถาม Pen Complex H2 [แยก] โดย Bryan Rasmussen ใช่แล้ว มีเส้นทางที่เป็นไปได้มากมายไปยังองค์ประกอบใดๆ ในการทดสอบโดยใช้ 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 ซึ่งเป็นพอร์ตไปยังเอ็นจิ้น Saxon XSLT, XQUERY และ XPath ของ JavaScript นั่นเป็นแนวคิดที่น่าสนใจ โดยเฉพาะอย่างยิ่งเมื่อ 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 และให้ตัวอย่างมากมายแก่คุณที่สาธิตวิธีใช้มันเพื่อให้บรรลุสิ่งที่ยิ่งใหญ่ มันเป็นตัวอย่างที่สมบูรณ์แบบของเทคโนโลยีรุ่นเก่าในสแต็กเบราว์เซอร์ที่ยังคงมีประโยชน์มากมายในปัจจุบัน แม้ว่าคุณจะไม่เคยรู้ว่ามันมีอยู่จริงหรือไม่เคยคิดที่จะเข้าถึงมันก็ตาม อ่านต่อ
“Enhancing the Resiliency of Automated Web Tests with Natural Language” (ACM Digital Library) โดย Maroun Ayli, Youssef Bakouny, Nader Jalloul และ Rima Kilany บทความนี้มีตัวอย่าง XPath มากมายสำหรับการเขียนการทดสอบแบบยืดหยุ่น XPath (MDN)นี่เป็นจุดเริ่มต้นที่ดีเยี่ยมหากคุณต้องการคำอธิบายทางเทคนิคที่ให้รายละเอียดวิธีการทำงานของ XPath XPath Tutorial (ZVON) ฉันพบว่าบทช่วยสอนนี้มีประโยชน์มากที่สุดในการเรียนรู้ของฉันเอง ต้องขอบคุณตัวอย่างมากมายและคำอธิบายที่ชัดเจน XPatherเครื่องมือแบบโต้ตอบนี้ช่วยให้คุณทำงานกับโค้ดได้โดยตรง
