Tại sao XSLT hiếm khi được sử dụng trên web? [đóng cửa]


12

XSLT là một tiêu chuẩn trưởng thành, được chấp nhận rộng rãi.

Nó có thể được sử dụng trong các trình duyệt (ngay cả trong IE cũ) và ở phía máy chủ (nginx có mô-đun XSLT, dĩ nhiên có thể được sử dụng từ các ngôn ngữ lập trình). Việc triển khai của nó được biên dịch và do đó, sẽ nhanh hơn nhiều so với Python hoặc JS. Việc triển khai JS Saxon JS có thể được sử dụng, ít nhất, như một dự phòng. Tạo khuôn mẫu Jinja, Angular, Ruby's Slim, ASP và PHP thậm chí không gần gũi.

Một mẫu XSL có thể được xác nhận dễ dàng trong IDE. Có bao nhiêu IDE có thể giúp với Jinja hoặc Angular?

Có vẻ như đó là một ý tưởng hoàn hảo để phân tách giao diện người dùng và dữ liệu với XSLT.

Phải thừa nhận rằng việc triển khai có thể cho kết quả khác nhau trong một số trường hợp góc, nhưng đó chỉ là vấn đề với việc tạo khuôn mẫu ở phía máy khách. Và nó cũng tương tự với HTML, CSS và mọi thứ khác được thực hiện ở phía máy khách.

Vậy, tại sao không XSLT?


4
JSON dễ hơn XML. Tôi không phải bạn, chỉ đêm qua tôi đã nghe các nhà phát triển nói rằng họ rất biết ơn rằng họ không bao giờ phải sử dụng XSLT nữa. Xem: stackoverflow.com/questions/4862310/json-and-xml-comparison
Dan Wilson

6
Bạn đã bao giờ thử làm một cái gì đó không cần thiết với nó?
PlasmaHH

9
Là 'bởi vì thật đau đớn khi sử dụng' một câu trả lời hợp lệ ..?
đây là

2
@thisextendsthat: Không, vì JavaScript và CSS cũng được sử dụng để sử dụng, nhưng vẫn được sử dụng rộng rãi.
JacquesB

4
@JacquesB JS và CSS vẫn còn đau đớn để sử dụng.
Andy

Câu trả lời:


39

XSLT không thực sự có vai trò hữu ích trong web tương tác hiện đại. Mục đích của XSLT là chuyển đổi từ ngôn ngữ XML này sang ngôn ngữ khác - nhưng thực sự bạn không bao giờ cần phải làm điều đó ngay từ đầu. Công nghệ mạnh mẽ, nhanh chóng và được hỗ trợ tốt như thế nào là không liên quan nếu bạn không gặp phải vấn đề mà công nghệ được thiết kế để giải quyết.

Có một số lý do khiến trường hợp sử dụng cho XSLT biến mất:

  • HTML đã thắng. XSLT được cho là hữu ích để chuyển đổi nội dung "văn bản phong phú" ở một số định dạng đánh dấu ngữ nghĩa sang HTML. Nhưng bản thân HTML là một định dạng hoàn toàn tốt, vậy tại sao không sử dụng nội dung đó cho nội dung ngay từ đầu và bỏ qua việc chuyển đổi?
  • CSS đã trở nên mạnh mẽ hơn nhiều. Một trong những lời hứa của XSLT là bạn có thể giữ đánh dấu nguồn sạch và ngữ nghĩa và sau đó chuyển đổi thành "HTML trình bày" hoạt động trên trình duyệt chéo và nơi bạn có thể sắp xếp lại các yếu tố, v.v. Nhưng bạn không thực sự cần HTML trình bày ngày nay, bạn có thể sử dụng HTML ngữ nghĩa và CSS có thể thực hiện kiểu dáng và bố cục cần thiết.
  • XML đã không trở thành định dạng phổ biến cho dữ liệu. Khi tìm nạp dữ liệu SQL từ cơ sở dữ liệu, sẽ đơn giản hơn nhiều khi chỉ cần trực tiếp hợp nhất nó vào một khuôn mẫu, thay vì trước tiên chuyển đổi nó thành XML và sau đó chuyển đổi nó thông qua XSLT. Và JSON có tất cả trừ XML thay thế cho dữ liệu có cấu trúc ở phía máy khách.
  • XSLT được thiết kế để chuyển đổi toàn bộ tài liệu tại một thời điểm. Nhưng trong các trang web tương tác hiện đại, các đoạn dữ liệu nhỏ được tải xuống từng phần và được hợp nhất vào trang.
  • Dữ liệu không quá phức tạp. Đối với phần lớn các trường hợp sử dụng, các định dạng mẫu đơn giản hơn với trình giữ chỗ và bộ lặp sẽ giải quyết công việc tốt. XSLT mạnh hơn nhiều, nhưng bạn hiếm khi cần thêm sức mạnh đó và nó có chi phí cao về độ phức tạp và xấu xí.

XSLT phát triển từ việc xuất bản nơi bạn có thể có quy trình một chiều từ một định dạng nguồn có cấu trúc sang nhiều định dạng xuất bản như in, PDF và các trang web tĩnh. Hầu hết các trang web không phù hợp với trường hợp sử dụng này.


Câu trả lời rất nhiều thông tin (+1).
Giorgio

1
Tôi không biết trải nghiệm của mình có giống với những người dùng khác không, nhưng một trong những "điểm bán" của XSLT như đã giải thích với tôi là giảm băng thông: nếu bạn có một trang lớn, thông thường, bạn sẽ gửi một XML ( <chapter><title><par>...) và XSLT tối thiểu sẽ "mở rộng" nó với div, table, trkhi cần thiết, với việc bổ sung rằng nó có thể được lưu trữ. Vì vậy (một lần nữa, tôi không biết "lợi thế" này được giải thích như thế nào) băng thông được cải thiện cũng sẽ làm tổn thương nó (và thực tế là hầu hết các trang HTML đều khá nhỏ).
SJuan76

@ SJuan76: Đó là một ý tưởng để chuyển đổi đánh dấu ngữ nghĩa thành HTML trình bày dài dòng sử dụng các bảng để bố trí. May mắn thay, không còn cần thiết phải sử dụng các bảng để bố trí để trường hợp sử dụng là moot.
JacquesB

@JacquesB Tôi đã sử dụng cặp vợ chồng đó cho trang đó: programaths.be/job/job.xml và nó đã làm cho hoàn hảo. XML được sử dụng để hiển thị trang VÀ kiểm tra các câu trả lời cho bảng câu hỏi được tạo. Đây không phải là về định dạng trong các bảng, nhưng XML cung cấp cho tôi một sự trừu tượng hóa tốt. Tất nhiên, tôi không quan tâm đến việc mọi người gian lận. Nhưng nó cho thấy rằng ngay cả trong thời hiện đại, nó có thể rất hữu ích!
chương trình

9

Phụ thuộc vào những gì bạn có nghĩa là "trong Web".

XSLT được sử dụng rất rộng rãi. Theo như chúng tôi có thể đánh giá từ các số liệu như số lượng câu hỏi StackOverflow, nó nằm trong 30 ngôn ngữ lập trình hàng đầu, có thể làm cho nó trở thành ngôn ngữ lập trình cụ thể theo mô hình dữ liệu hàng đầu sau SQL.

Nhưng XSLT không được sử dụng rộng rãi phía máy khách, nghĩa là trong trình duyệt. Nó thường được sử dụng ở phía máy chủ để phân phối nội dung theo yêu cầu để đáp ứng các yêu cầu HTTP hoặc nó được sử dụng trong chế độ hàng loạt như một phần của quy trình xuất bản. Tất nhiên, nó cũng được sử dụng trong nhiều ứng dụng có rất ít liên quan đến web, ví dụ như trong xuất bản in.

Có một số lý do XSLT không được sử dụng rộng rãi trong trình duyệt. Lý do chính là sự hỗ trợ XSLT tuân thủ tốt rất chậm đến từ các nhà cung cấp trình duyệt; không ai muốn sử dụng nó cho đến khi nó có sẵn trên mọi trình duyệt và vào thời điểm nó có sẵn trên mọi trình duyệt, những điều mọi người muốn làm trong trình duyệt đã chuyển sang (nhớ "Web 2.0"?) và triển khai XSLT trong trình duyệt không giúp bạn xây dựng các ứng dụng tương tác hoặc tìm nạp dữ liệu bằng AJAX.

Saxonica (từ chối trách nhiệm, đây là sản phẩm của tôi) đã cố gắng cắm những khoảng trống này với Saxon-JS, nhưng sản phẩm này là một người đến muộn cho bữa tiệc, và sự phát triển web của khách hàng rất thời trang, vì vậy không đủ để chỉ có một sản phẩm đánh dấu vào tất cả các hộp kỹ thuật. Một phần của xu hướng thời trang là hầu hết các trang web hướng dữ liệu (khác với định hướng tài liệu) đã chuyển sang JSON thay vì XML, phần lớn là do JSON dễ thao tác hơn từ Javascript.

Vấn đề khác là XSLT là ngôn ngữ yêu hay ghét. Mô hình khai báo, dựa trên quy tắc, định hướng chức năng của nó hấp dẫn nhiều người vì tính chất cấp cao của nó, nhưng có thể gây khó chịu cho những người có kinh nghiệm lập trình duy nhất là viết mã bắt buộc cho máy tính biết chính xác những gì cần làm và trong thứ tự nào


3

Tôi lật lọng qua lại giữa việc trả lời câu hỏi này và đóng nó dưới dạng chủ yếu dựa trên quan điểm. Vì vậy, đây là lật của tôi:

Nói tóm lại, vì XML tạo ra một ngôn ngữ lập trình tào lao. Một cái gì đó với ngữ nghĩa của XSLT nhưng cú pháp tốt hơn nhiều sẽ là một vấn đề hoàn toàn khác, tôi nghĩ vậy. Ví dụ, có một số ngôn ngữ chuyển đổi XML dựa trên Lisp thực sự thú vị.

XSLT không thể quyết định liệu nó muốn trở thành ngôn ngữ viết lại cây, ngôn ngữ chức năng hay ngôn ngữ thủ tục. Nó có các tính năng của tất cả những thứ đó, nhưng nó không thực sự tốt ở bất kỳ trong số chúng. Đối với bất kỳ trong ba khía cạnh, có những ngôn ngữ tốt hơn ra khỏi đó.


Cú pháp XML thực sự có thể trông dài dòng. Nhưng, một số ngôn ngữ khác được hỗ trợ ở khắp mọi nơi là gì?
George Sovetov

XSLT là một ngôn ngữ chức năng tuyệt vời IMO. Nơi nó rơi xuống là cách nó trộn logic xem w / biến đổi.
RubberDuck

4
@GeorgeSoverov tại sao điều quan trọng là được hỗ trợ ở mọi nơi? Nó chỉ cần được hỗ trợ trên máy chủ của bạn.
Esben Skov Pedersen

1
Tôi nghĩ rằng sự xấu xí của một ngôn ngữ là không liên quan nếu nó phục vụ một trường hợp sử dụng có liên quan. Chỉ cần chứng kiến ​​sự thành công của JavaScript. Vấn đề với XSLT là trường hợp sử dụng không có ở đó.
JacquesB

1
Chà, bạn chắc chắn đã chứng minh rằng đó là một câu hỏi thu hút các câu trả lời dựa trên quan điểm ...
Michael Kay

0

Bởi vì bản thân XML trông giống như rác tương thích ngược đã lỗi thời cho 99,9% trường hợp.

Trường hợp sử dụng duy nhất mà XML không có sự thay thế vượt trội ngay lập tức là những thứ như docx hoặc odf và có thể SGML sẽ tốt hơn *. Đó là, chúng tôi có cấu trúc tài liệu vô cùng phong phú với tất cả các loại được lồng vào nhau với các biến đổi lớn được áp dụng để nó có thể xuất hiện chính xác trên màn hình và máy in.

Hầu như mọi lúc, XML được sử dụng để truyền dữ liệu có cấu trúc xung quanh và dường như XSLT được thiết kế để chuyển đổi dữ liệu tài liệu có cấu trúc thành dữ liệu tài liệu. Trường hợp sử dụng đang chết dần. JSON trực tiếp vượt trội hơn XML đối với dữ liệu có cấu trúc. ** Cả markdown và YAML đều vượt trội ở dữ liệu được định dạng nhẹ. Dự phòng ban đầu của XML là các trình phân tích cú pháp tích hợp trong Java và Javacript. JSON đã phá vỡ rào cản đó bằng cách tận dụng trình phân tích cú pháp tích hợp cho các trường hợp nguồn JSON được tin cậy (hầu hết trong số đó khi còn trẻ).

Và thế giới đã thay đổi. Lợi thế thư viện tích hợp là một lợi thế tầm thường bây giờ. XHTML đã bị từ chối hoàn toàn và sự thay thế của nó không được thừa hưởng từ nó mà từ người tiền nhiệm của nó.

XML hiện được sử dụng để nói chuyện trực tiếp với anh chàng muốn nhận nó và nó được tạo ra trong toàn bộ trang phục theo định dạng mong muốn, hoặc ngược lại, nó được đọc và phân tích thành mô hình đối tượng trực tiếp từ biểu mẫu được gửi đi. Vì nó không còn là định dạng lưu trữ hoặc định dạng trao đổi chung, chuyển đổi nó từ lược đồ sang lược đồ không còn cần thiết nữa.

* Họ đã dạy ở trường đại học rằng SGML không bao giờ được thực hiện. Họ đã nói dối.

** Tôi đã nghe những phàn nàn về các định dạng số xấu trong JSON. Mặt khác, XML không có định dạng số, vì vậy chỉ cần nhồi tất cả các loại dữ liệu trong chuỗi vẫn chiến thắng so với XML.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.