Tôi đã làm việc trong lĩnh vực phát triển front-end đủ lâu để nhận ra xu hướng trong những năm qua: các nhà phát triển trẻ hơn làm việc với một mô hình lập trình mới mà không hiểu bối cảnh lịch sử của nó. Tất nhiên, việc không biết điều gì đó là điều hoàn toàn dễ hiểu. Trang web là một nơi rất rộng lớn với nhiều kỹ năng và chuyên môn đa dạng và không phải lúc nào chúng ta cũng biết những gì mình không biết. Học tập trong lĩnh vực này là một hành trình liên tục chứ không phải là điều gì đó xảy ra một lần rồi kết thúc. Trường hợp cụ thể: Một người nào đó trong nhóm của tôi đã hỏi liệu có thể biết liệu người dùng có điều hướng khỏi một tab cụ thể trong giao diện người dùng hay không. Tôi đã chỉ ra sự kiện beforeunload của JavaScript. Nhưng những người đã giải quyết vấn đề này trước đây đều biết điều này có thể xảy ra vì họ đã nhận được cảnh báo về dữ liệu chưa được lưu trên các trang web khác, mà beforeunload là một trường hợp sử dụng điển hình. Tôi cũng đã chỉ ra các sự kiện trangẨn và hiển thịThay đổi cho đồng nghiệp của tôi để có biện pháp tốt. Làm sao tôi biết được điều đó? Bởi vì nó xuất hiện trong một dự án khác chứ không phải vì tôi đã nghiên cứu về nó khi mới học JavaScript. Thực tế là các framework front-end hiện đại đang đứng trên vai những gã khổng lồ công nghệ đi trước họ. Chúng trừu tượng hóa các phương pháp phát triển, thường mang lại trải nghiệm tốt hơn cho nhà phát triển, làm giảm hoặc thậm chí loại bỏ nhu cầu biết hoặc chạm vào những gì theo truyền thống là khái niệm giao diện người dùng thiết yếu mà mọi người có lẽ nên biết. Hãy xem xét Mô hình đối tượng CSS (CSSOM). Bạn có thể mong đợi rằng bất kỳ ai làm việc về CSS và JavaScript đều có nhiều trải nghiệm CSSOM thực tế, nhưng điều đó không phải lúc nào cũng đúng. Có một dự án React cho một trang web thương mại điện tử mà tôi đã làm việc trong đó chúng tôi cần tải biểu định kiểu cho nhà cung cấp thanh toán hiện được chọn. Vấn đề là biểu định kiểu được tải trên mọi trang khi nó chỉ thực sự cần thiết trên một trang cụ thể. Nhà phát triển được giao nhiệm vụ thực hiện điều này chưa bao giờ tải biểu định kiểu một cách linh hoạt. Một lần nữa, điều này hoàn toàn dễ hiểu khi React loại bỏ cách tiếp cận truyền thống mà bạn có thể đã hướng tới. CSSOM có thể không phải là thứ bạn cần trong công việc hàng ngày. Nhưng có thể bạn sẽ cần phải tương tác với nó vào một lúc nào đó, ngay cả trong trường hợp chỉ xảy ra một lần. Những kinh nghiệm này đã truyền cảm hứng cho tôi viết bài này. Có rất nhiều tính năng và công nghệ web hiện có mà bạn có thể không bao giờ chạm trực tiếp vào công việc hàng ngày của mình. Có lẽ bạn là người mới bắt đầu phát triển web và đơn giản là không biết về chúng vì bạn đang chìm đắm trong sự trừu tượng của một khuôn khổ cụ thể mà không yêu cầu bạn phải biết sâu về nó, hoặc thậm chí là không. Tôi đang nói cụ thể về XML, thứ mà nhiều người trong chúng ta biết là một ngôn ngữ cổ xưa không hoàn toàn khác với HTML. Tôi đưa ra vấn đề này vì các cuộc thảo luận gần đây về WHATWG gợi ý rằng một phần đáng kể của ngăn xếp XML được gọi là lập trình XSLT cần được loại bỏ khỏi trình duyệt. Đây chính xác là loại công nghệ cũ hơn, hiện có mà chúng tôi đã có trong nhiều năm và có thể được sử dụng cho những việc thiết thực như tình huống CSSOM mà nhóm của tôi đang gặp phải. Bạn đã từng làm việc với XSLT trước đây chưa? Hãy xem liệu chúng ta có dựa nhiều vào công nghệ cũ hơn này và tận dụng các tính năng của nó bên ngoài bối cảnh XML để giải quyết các vấn đề trong thế giới thực ngày nay hay không. XPath: API trung tâm Công nghệ XML quan trọng nhất có lẽ hữu ích nhất ngoài phối cảnh XML thẳng là XPath, một ngôn ngữ truy vấn cho phép bạn tìm bất kỳ nút hoặc thuộc tính nào trong cây đánh dấu với một phần tử gốc. Tôi có tình cảm cá nhân với XSLT, nhưng điều đó cũng phụ thuộc vào XPath và tình cảm cá nhân phải được đặt sang một bên trong tầm quan trọng của việc xếp hạng. Lập luận để loại bỏ XSLT không đề cập đến XPath, vì vậy tôi cho rằng nó vẫn được cho phép. Điều đó tốt vì XPath là API trung tâm và quan trọng nhất trong bộ công nghệ này, đặc biệt là khi cố gắng tìm thứ gì đó để sử dụng ngoài việc sử dụng XML thông thường. Điều này quan trọng vì mặc dù bộ chọn CSS có thể được sử dụng để tìm hầu hết các thành phần trong trang của bạn nhưng chúng không thể tìm thấy tất cả. Hơn nữa, không thể sử dụng bộ chọn CSS để tìm một phần tử dựa trên vị trí hiện tại của nó trong DOM. XPath có thể. Bây giờ, một số bạn đang đọc bài viết này có thể biết XPath, còn một số thì không. XPath là một lĩnh vực công nghệ khá lớn và tôi thực sự không thể dạy tất cả những điều cơ bản cũng như chỉ cho bạn những điều thú vị để làm với nó chỉ trong một bài viết như thế này. Tôi thực sự đã cố gắng viết bài báo đó, nhưng ấn phẩm trung bình của Tạp chí Smashing không vượt quá 5.000 từ. Tôi đã ở hơn2.000 từ trong khi chỉ mới học được một nửa kiến thức cơ bản. Vì vậy, tôi sẽ bắt đầu làm những điều thú vị với XPath và cung cấp cho bạn một số liên kết mà bạn có thể sử dụng cho những điều cơ bản nếu bạn thấy nội dung này thú vị. Kết hợp XPath & CSS XPath có thể thực hiện nhiều việc mà bộ chọn CSS không thể thực hiện được khi truy vấn các phần tử. Nhưng bộ chọn CSS cũng có thể thực hiện một số điều mà XPath không thể, cụ thể là truy vấn các phần tử theo tên lớp.
CSS XPath .myClass /*[chứa(@class, "myClass")]
Trong ví dụ này, CSS truy vấn các phần tử có chứa tên lớp .myClass. Trong khi đó, ví dụ XPath truy vấn các phần tử chứa một lớp thuộc tính có chuỗi “myClass”. Nói cách khác, nó chọn các phần tử có myClass trong bất kỳ thuộc tính nào, bao gồm các phần tử có tên lớp .myClass — cũng như các phần tử có “myClass” trong chuỗi, chẳng hạn như .myClass2. XPath rộng hơn theo nghĩa đó. Vì vậy, không. Tôi không gợi ý rằng chúng ta nên loại bỏ CSS và bắt đầu chọn tất cả các phần tử thông qua XPath. Đó không phải là vấn đề. Vấn đề là XPath có thể làm những việc mà CSS không thể và vẫn có thể rất hữu ích, mặc dù đây là một công nghệ cũ hơn trong trình duyệt và thoạt nhìn có vẻ không rõ ràng. Chúng ta hãy sử dụng hai công nghệ cùng nhau không chỉ vì chúng ta có thể mà còn vì chúng ta sẽ tìm hiểu điều gì đó về XPath trong quá trình này, biến nó thành một công cụ khác trong ngăn xếp của bạn - một công cụ mà bạn có thể chưa biết đã có từ lâu! Vấn đề là phương thức document.evaluate của JavaScript và các phương thức chọn truy vấn khác nhau mà chúng tôi sử dụng với API CSS cho JavaScript không tương thích. Tôi đã tạo một API truy vấn tương thích để giúp chúng ta bắt đầu, mặc dù phải thừa nhận rằng tôi chưa suy nghĩ nhiều về nó vì nó khác xa với những gì chúng tôi đang làm ở đây. Đây là một ví dụ hoạt động khá đơn giản về hàm tạo truy vấn có thể sử dụng lại: Xem Pen queryXPath [rẽ nhánh] của Bryan Rasmussen. Tôi đã thêm hai phương thức trên đối tượng tài liệu: queryCSSSelectors (về cơ bản là querySelectorAll) và queryXPaths. Cả hai đều trả về một đối tượng queryResults:
{ loại truy vấn: nút | chuỗi | số | Boolean, kết quả: bất kỳ[] // phần tử html, phần tử xml, chuỗi, số, booleans, queryCSSSelectors: (truy vấn: chuỗi, sửa đổi: boolean) => queryResults, queryXpaths: (truy vấn: chuỗi, sửa đổi: boolean) => queryResults }
Tất nhiên, các hàm queryCSSSelectors và queryXpaths chạy truy vấn mà bạn cung cấp cho chúng trên các phần tử trong mảng kết quả, miễn là mảng kết quả thuộc loại nút. Nếu không, nó sẽ trả về một queryResult với một mảng trống và một loại nút. Nếu thuộc tính sửa đổi được đặt thành true, các hàm sẽ thay đổi kết quả truy vấn của riêng chúng. Trong mọi trường hợp, điều này không nên được sử dụng trong môi trường sản xuất. Tôi đang làm theo cách này hoàn toàn để chứng minh những tác động khác nhau của việc sử dụng hai API truy vấn cùng nhau. Truy vấn mẫu Tôi muốn đưa ra một vài ví dụ về các truy vấn XPath khác nhau để chứng minh một số điều mạnh mẽ mà chúng có thể thực hiện và cách chúng có thể được sử dụng thay cho các phương pháp tiếp cận khác. Ví dụ đầu tiên là //li/text(). Điều này truy vấn tất cả các phần tử li và trả về các nút văn bản của chúng. Vì vậy, nếu chúng ta truy vấn HTML sau:
- một
- hai
- ba
…đây là những gì được trả về:
{"queryType:"xpathEvaluate","results":["một","hai","ba"],"resultType://string"}
Nói cách khác, chúng ta nhận được mảng sau: ["one","hai","ba"]. Thông thường, bạn sẽ truy vấn các phần tử li để nhận được phần tử đó, chuyển kết quả của truy vấn đó thành một mảng, ánh xạ mảng đó và trả về nút văn bản của từng phần tử. Nhưng chúng ta có thể làm điều đó chính xác hơn với XPath: document.queryXPaths("//li/text()").kết quả.
Lưu ý rằng cách để có được nút văn bản là sử dụng text(), trông giống như chữ ký hàm - và đúng như vậy. Nó trả về nút văn bản của một phần tử. Trong ví dụ của chúng tôi, có ba phần tử li trong đánh dấu, mỗi phần tử chứa văn bản ("một", "hai" và "ba").
Hãy xem thêm một ví dụ khác về truy vấn text(). Giả sử đây là đánh dấu của chúng tôi:
Hãy viết một truy vấn trả về giá trị thuộc tính href: document.queryXPaths("//a[text() = 'Đăng nhập']/@href").kết quả.
Đây là truy vấn XPath trên tài liệu hiện tại, giống như ví dụ trước, nhưng lần này chúng tôi trả về thuộc tính href của một liên kết (một phần tử) có chứa văn bản “Đăng nhập”. Thực tế trả lạikết quả là ["/login.html"]. Tổng quan về hàm XPath Có một số hàm XPath và có thể bạn chưa quen với chúng. Tôi nghĩ có một số điều đáng để biết, bao gồm những điều sau:
started-withNếu một văn bản bắt đầu bằng một ví dụ văn bản cụ thể khác, started-with(@href, 'http:') trả về true nếu thuộc tính href bắt đầu bằng http:. chứaNếu một văn bản chứa một ví dụ văn bản cụ thể khác, contains(text(), "Smashing Magazine") trả về true nếu một nút văn bản chứa các từ “Smashing Magazine” ở bất cứ đâu trong đó. countTrả về số lượng kết quả phù hợp với một truy vấn. Ví dụ: count(//*[starts-with(@href, 'http:']) trả về số lượng liên kết trong nút ngữ cảnh có các phần tử có thuộc tính href chứa văn bản bắt đầu bằng http:. chuỗi conHoạt động giống như chuỗi con JavaScript, ngoại trừ việc bạn chuyển chuỗi đó làm đối số. Ví dụ: chuỗi con("my text", 2, 4) trả về "y t". chuỗi con trướcTrả về phần của chuỗi trước chuỗi khác. Ví dụ: substing-Before("my text", " ") trả về "my". Tương tự, substring-Before("hi","bye") trả về một chuỗi trống. substring-afterTrả về phần của chuỗi sau chuỗi khác. Ví dụ: substing-after("my text", " ") trả về "text". Tương tự, substring-after("hi","bye") trả về một chuỗi trống. normalize-spaceTrả về chuỗi đối số có khoảng trắng được chuẩn hóa bằng cách loại bỏ khoảng trắng ở đầu và cuối và thay thế chuỗi ký tự khoảng trắng bằng một khoảng trắng. notTrả về giá trị boolean true nếu đối số sai, nếu không thì sai. trueTrả về boolean true. falseTrả về boolean sai. concatĐiều tương tự như concat JavaScript, ngoại trừ việc bạn không chạy nó như một phương thức trên một chuỗi. Thay vào đó, bạn đưa vào tất cả các chuỗi bạn muốn nối. string-lengthThis không giống với string-length của JavaScript mà trả về độ dài của chuỗi mà nó được đưa ra làm đối số. TranslateThis nhận vào một chuỗi và thay đổi đối số thứ hai thành đối số thứ ba. Ví dụ: dịch("abcdef", "abc", "XYZ") xuất ra XYZdef.
Ngoài các hàm XPath cụ thể này, còn có một số hàm khác hoạt động giống như các hàm tương tự JavaScript của chúng — hoặc các hàm tương tự về cơ bản là bất kỳ ngôn ngữ lập trình nào — mà bạn có thể cũng sẽ thấy hữu ích, chẳng hạn như sàn, trần, tròn, tổng, v.v. Bản demo sau minh họa từng chức năng này: Xem các hàm số Pen XPath [rẽ nhánh] của Bryan Rasmussen. Lưu ý rằng, giống như hầu hết các hàm thao tác chuỗi, nhiều hàm số có một đầu vào duy nhất. Tất nhiên, điều này là do chúng được cho là được sử dụng để truy vấn, như trong ví dụ XPath cuối cùng: //li[sàn(text()) > 250]/@val
Nếu bạn sử dụng chúng, như hầu hết các ví dụ đều làm, bạn sẽ chạy nó trên nút đầu tiên khớp với đường dẫn. Ngoài ra còn có một số chức năng chuyển đổi loại mà bạn có thể nên tránh vì JavaScript đã có vấn đề về chuyển đổi loại riêng. Nhưng có thể đôi khi bạn muốn chuyển đổi một chuỗi thành một số để kiểm tra nó với một số khác. Các hàm thiết lập kiểu của một cái gì đó là boolean, number, string và node. Đây là những kiểu dữ liệu XPath quan trọng. Và như bạn có thể tưởng tượng, hầu hết các hàm này có thể được sử dụng trên các kiểu dữ liệu không phải là nút DOM. Ví dụ: substring-after lấy một chuỗi như chúng ta đã trình bày, nhưng nó có thể là chuỗi từ thuộc tính href. Nó cũng có thể chỉ là một chuỗi:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Rõ ràng, ví dụ này sẽ trả lại cho chúng ta mảng kết quả là ["world"]. Để thể hiện điều này trong thực tế, tôi đã tạo một trang demo bằng cách sử dụng các hàm đối với những thứ không phải là nút DOM: Xem Pen queryXPath [rẽ nhánh] của Bryan Rasmussen. Bạn nên lưu ý khía cạnh đáng ngạc nhiên của hàm dịch, đó là nếu bạn có một ký tự trong đối số thứ hai (tức là danh sách các ký tự bạn muốn dịch) và không có ký tự phù hợp để dịch sang thì ký tự đó sẽ bị xóa khỏi đầu ra. Vì vậy, điều này:
dịch('Xin chào, tên tôi là Inigo Montoya, bạn đã giết cha tôi, chuẩn bị chết','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…kết quả trong chuỗi, bao gồm cả dấu cách: [" * * ** "]
Điều này có nghĩa là chữ cái “a” đang được dịch sang dấu hoa thị (*), nhưng mọi ký tự khác không có bản dịch cho chuỗi đích sẽ bị loại bỏ hoàn toàn. Khoảng trắng là tất cả những gì chúng ta còn lạigiữa các ký tự “a” được dịch. Sau đó, một lần nữa, truy vấn này:
dịch('Xin chào, tên tôi là Inigo Montoya, bạn đã giết cha tôi, chuẩn bị chết','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','******************************************************')")")
…không gặp vấn đề gì và cho ra kết quả như thế này:
"****** ** **** ** ***** ******* *** ****** ** ******* ******* ** ***"
Bạn có thể chợt nhận ra rằng không có cách nào dễ dàng trong JavaScript để thực hiện chính xác những gì hàm dịch XPath thực hiện, mặc dù trong nhiều trường hợp sử dụng, việc thay thế All bằng các biểu thức thông thường có thể xử lý được việc đó. Bạn có thể sử dụng cách tiếp cận tương tự mà tôi đã trình bày, nhưng cách đó chưa tối ưu nếu tất cả những gì bạn muốn là dịch chuỗi. Bản demo sau bao gồm chức năng dịch của XPath để cung cấp phiên bản JavaScript: Xem chức năng Pen dịch [rẽ nhánh] của Bryan Rasmussen. Bạn có thể sử dụng thứ gì đó như thế này ở đâu? Hãy xem xét mã hóa Mật mã Caesar với độ lệch ba vị trí (ví dụ: mã hóa hàng đầu từ năm 48 trước Công nguyên):
dịch("Caesar đang có ý định vượt qua Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Văn bản đầu vào “Caesar đang có ý định vượt qua Rubicon!” kết quả là “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Để đưa ra một ví dụ nhanh khác về các khả năng khác nhau, tôi đã tạo một hàm kim loại nhận đầu vào chuỗi và sử dụng hàm dịch để trả về văn bản, bao gồm tất cả các ký tự lấy âm sắc. Xem chức năng Pen metal [phân nhánh] của Bryan Rasmussen.
const kim loại = (str) => { return dịch(str, "AOUaou","ÄÖÜäöü"); }
Và, nếu được đưa ra dòng chữ “Quy tắc Motley Crue, hãy đá lên các chàng trai!”, sẽ trả về “Mötley Crüe rüles, röck ön düdes!” Rõ ràng, người ta có thể có đủ kiểu sử dụng chức năng này để nhại lại. Nếu đó là bạn thì bài viết TVTropes này sẽ mang đến cho bạn nhiều cảm hứng. Sử dụng CSS với XPath Hãy nhớ lý do chính của chúng ta khi sử dụng bộ chọn CSS cùng với XPath: CSS hiểu khá rõ lớp là gì, trong khi điều tốt nhất bạn có thể làm với XPath là so sánh chuỗi của thuộc tính lớp. Điều đó sẽ hiệu quả trong hầu hết các trường hợp. Nhưng nếu bạn đã từng gặp phải tình huống, chẳng hạn như ai đó đã tạo các lớp có tên .primaryLinks và .primaryLinks2 và bạn đang sử dụng XPath để nhận lớp .primaryLinks, thì bạn có thể gặp phải sự cố. Miễn là không có gì ngớ ngẩn như vậy, bạn có thể sẽ sử dụng XPath. Nhưng tôi rất buồn khi phải thông báo rằng tôi đã làm việc ở những nơi mà mọi người làm những việc ngớ ngẩn như vậy. Đây là một bản demo khác sử dụng CSS và XPath cùng nhau. Nó cho thấy điều gì xảy ra khi chúng ta sử dụng mã để chạy XPath trên nút ngữ cảnh không phải là nút của tài liệu. Xem Pen css và xpath cùng nhau [phân nhánh] của Bryan Rasmussen. Truy vấn CSS là .reledarticles a, truy vấn này tìm nạp hai phần tử a trong div được gán lớp .relativearticles. Sau đó là ba truy vấn “xấu”, nghĩa là các truy vấn không thực hiện những gì chúng ta muốn chúng thực hiện khi chạy với các phần tử này làm nút ngữ cảnh. Tôi có thể giải thích tại sao họ cư xử khác với những gì bạn mong đợi. Ba truy vấn xấu được đề cập là:
//text(): Trả về toàn bộ văn bản trong tài liệu. //a/text(): Trả về tất cả văn bản bên trong các liên kết trong tài liệu. ./a/text(): Không trả về kết quả nào.
Lý do cho những kết quả này là vì trong khi ngữ cảnh của bạn là một phần tử được trả về từ truy vấn CSS, // lại đi ngược lại toàn bộ tài liệu. Đây là điểm mạnh của XPath; CSS không thể đi từ một nút lên đến tổ tiên rồi đến anh chị em của tổ tiên đó và đi xuống con cháu của anh chị em đó. Nhưng XPath có thể. Trong khi đó, ./ truy vấn các nút con của nút hiện tại, trong đó dấu chấm (.) đại diện cho nút hiện tại và dấu gạch chéo lên (/) biểu thị việc đi đến một nút con nào đó - cho dù đó là thuộc tính, phần tử hay văn bản được xác định bởi phần tiếp theo của đường dẫn. Nhưng không có phần tử con nào được truy vấn CSS chọn, do đó truy vấn đó cũng không trả về kết quả gì. Có ba truy vấn hay trong bản demo cuối cùng đó:
.//văn bản(), ./text(), normalize-space(./text()).
Truy vấn chuẩn hóa không gian thể hiện cách sử dụng hàm XPath nhưng cũng khắc phục sự cố có trong các truy vấn khác. HTML có cấu trúc như thế này:
Tự động hóa việc kiểm tra tính năng của bạn với Selenium WebDriver
Truy vấn trả về nguồn cấp dữ liệu ở đầu và cuối nút văn bản,và normalize-space loại bỏ điều này. Việc sử dụng bất kỳ hàm XPath nào trả về một giá trị nào đó không phải là boolean có XPath đầu vào sẽ áp dụng cho các hàm khác. Bản demo sau đây cho thấy một số ví dụ: Xem các ví dụ về hàm Pen xpath [rẽ nhánh] của Bryan Rasmussen. Ví dụ đầu tiên cho thấy một vấn đề bạn nên chú ý. Cụ thể là đoạn mã sau:
document.queryXPaths("substring-after(//a/@href,'https://')");
…trả về một chuỗi:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Nó có ý nghĩa, phải không? Các hàm này không trả về mảng mà trả về các chuỗi đơn hoặc số đơn. Chạy hàm ở bất kỳ đâu có nhiều kết quả chỉ trả về kết quả đầu tiên. Kết quả thứ hai cho thấy những gì chúng tôi thực sự muốn:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Trả về một mảng gồm hai chuỗi:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Các hàm XPath có thể được lồng vào nhau giống như các hàm trong JavaScript. Vì vậy, nếu chúng ta biết cấu trúc URL của Tạp chí Smashing, chúng ta có thể thực hiện các thao tác sau (nên sử dụng các chữ mẫu): `dịch( chuỗi con( chuỗi con sau(./@href, ‘www.smashingmagazine.com/') ,9), '/','')`
Điều này hơi phức tạp đến mức nó cần nhận xét mô tả chức năng của nó: lấy tất cả URL từ thuộc tính href sau www.smashingmagazine.com/, xóa chín ký tự đầu tiên, sau đó dịch ký tự gạch chéo lên (/) thành không có gì để loại bỏ dấu gạch chéo lên phía trước ở cuối. Mảng kết quả:
["kiểm tra tính năng-selenium-webdriver","kiểm tra tự động-kết quả-cải thiện khả năng truy cập"]
Các trường hợp sử dụng XPath khác XPath thực sự có thể tỏa sáng trong quá trình thử nghiệm. Lý do không khó thấy, vì XPath có thể được sử dụng để lấy mọi phần tử trong DOM, từ bất kỳ vị trí nào trong DOM, trong khi CSS thì không thể. Bạn không thể tin tưởng rằng các lớp CSS vẫn nhất quán trong nhiều hệ thống xây dựng hiện đại, nhưng với XPath, chúng tôi có thể tạo ra các kết quả khớp chắc chắn hơn về nội dung văn bản của một phần tử, bất kể cấu trúc DOM có thay đổi hay không. Đã có nghiên cứu về các kỹ thuật cho phép bạn thực hiện các bài kiểm tra XPath linh hoạt. Không có gì tệ hơn việc các bài kiểm tra bị lỗi và thất bại chỉ vì bộ chọn CSS không còn hoạt động vì nội dung nào đó đã bị đổi tên hoặc xóa. XPath cũng thực sự tuyệt vời trong việc trích xuất nhiều bộ định vị. Có nhiều cách để sử dụng truy vấn XPath để khớp với một phần tử. Điều này cũng đúng với CSS. Nhưng các truy vấn XPath có thể đi sâu vào mọi thứ theo cách có mục tiêu hơn nhằm hạn chế những gì được trả về, cho phép bạn tìm một kết quả phù hợp cụ thể trong đó có thể có một số kết quả phù hợp có thể xảy ra. Ví dụ: chúng ta có thể sử dụng XPath để trả về một phần tử h2 cụ thể được chứa bên trong một div ngay sau div anh chị em, đến lượt nó, chứa một phần tử hình ảnh con có thuộc tính data-testID="leader" trên đó:
không hiểu dòng tiêu đề này
Cũng đừng hiểu dòng tiêu đề này
Tiêu đề cho hình ảnh lãnh đạo
Đây là truy vấn: document.queryXPaths(` //div[ anh chị em sau::div[1] /img[@data-testID='lãnh đạo'] ] /h2/ văn bản() `);
Hãy xem bản demo để xem tất cả kết hợp với nhau như thế nào: Xem Truy vấn Pen Complex H2 [rẽ nhánh] của Bryan Rasmussen. Vì vậy, vâng. Có rất nhiều đường dẫn có thể đến bất kỳ phần tử nào trong thử nghiệm bằng XPath. Ngừng sử dụng XSLT 1.0 Tôi đã đề cập sớm rằng nhóm Chrome có kế hoạch loại bỏ hỗ trợ XSLT 1.0 khỏi trình duyệt. Điều đó quan trọng vì XSLT 1.0 sử dụng lập trình tập trung vào XML để chuyển đổi tài liệu, do đó, dựa vào XPath 1.0, vốn có trong hầu hết các trình duyệt. Khi điều đó xảy ra, chúng ta sẽ mất đi một thành phần quan trọng của XPath. Nhưng với thực tế là XPath thực sự tuyệt vời cho việc viết bài kiểm tra, tôi thấy rằng toàn bộ XPath sẽ không sớm biến mất. Điều đó nói lên rằng, tôi nhận thấy rằng mọi người sẽ quan tâm đến một tính năng khi nó bị loại bỏ. Và điều đó chắc chắn đúng trong trường hợp XSLT 1.0 không được dùng nữa. Có toàn bộ cuộc thảo luận diễn ra tại Hacker News với đầy những lập luận phản đối việc ngừng sử dụng. Bản thân bài đăng này là một ví dụ tuyệt vời về việc tạo một khung viết blog bằng XSLT. Bạncó thể tự mình đọc phần thảo luận nhưng nó đề cập đến cách JavaScript có thể được sử dụng làm công cụ hỗ trợ cho XLST để xử lý các loại trường hợp đó. Tôi cũng đã thấy các đề xuất rằng các trình duyệt nên sử dụng SaxonJS, một cổng cho các công cụ Saxon XSLT, XQUERY và XPath của JavaScript. Đó là một ý tưởng thú vị, đặc biệt là khi Saxon-JS triển khai phiên bản hiện tại của các thông số kỹ thuật này, trong khi không có trình duyệt nào triển khai bất kỳ phiên bản XPath hoặc XSLT nào ngoài 1.0 và không có trình duyệt nào triển khai XQuery. Tôi đã liên hệ với Norm Tovey-Walsh tại Saxonica, công ty đứng sau SaxonJS và các phiên bản khác của công cụ Saxon. Anh ấy nói: “Nếu bất kỳ nhà cung cấp trình duyệt nào quan tâm đến việc sử dụng SaxonJS làm điểm khởi đầu để tích hợp các công nghệ XML hiện đại vào trình duyệt, thì chúng tôi rất vui được thảo luận về vấn đề đó với họ.”- Norm Tovey-Walsh
Nhưng cũng nói thêm: "Tôi sẽ rất ngạc nhiên nếu có ai đó nghĩ rằng việc sử dụng SaxonJS ở dạng hiện tại và thả nó vào bản dựng trình duyệt không thay đổi sẽ là cách tiếp cận lý tưởng. Một nhà cung cấp trình duyệt, về bản chất là họ xây dựng trình duyệt, có thể tiếp cận sự tích hợp ở mức độ sâu hơn nhiều so với những gì chúng ta có thể 'từ bên ngoài'."- Norm Tovey-Walsh
Điều đáng chú ý là nhận xét của Tovey-Walsh được đưa ra khoảng một tuần trước thông báo ngừng sử dụng XSLT. Kết luận Tôi có thể tiếp tục. Nhưng tôi hy vọng điều này đã chứng minh được sức mạnh của XPath và cung cấp cho bạn nhiều ví dụ minh họa cách sử dụng nó để đạt được những điều tuyệt vời. Đó là một ví dụ hoàn hảo về công nghệ cũ hơn trong ngăn xếp trình duyệt vẫn còn nhiều tiện ích ngày nay, ngay cả khi bạn chưa bao giờ biết nó tồn tại hoặc chưa bao giờ cân nhắc việc tiếp cận nó. Đọc thêm
“Nâng cao khả năng phục hồi của các bài kiểm tra web tự động bằng ngôn ngữ tự nhiên” (Thư viện kỹ thuật số ACM) của Maroun Ayli, Youssef Bakouny, Nader Jalloul và Rima Kilany. Bài viết này cung cấp nhiều ví dụ XPath để viết các bài kiểm tra có khả năng phục hồi. XPath (MDN)Đây là nơi tuyệt vời để bắt đầu nếu bạn muốn có giải thích kỹ thuật chi tiết về cách XPath hoạt động. Hướng dẫn XPath (ZVON)Tôi nhận thấy hướng dẫn này hữu ích nhất cho quá trình học tập của tôi nhờ có vô số ví dụ và giải thích rõ ràng. XPatherCông cụ tương tác này cho phép bạn làm việc trực tiếp với mã.
