Có bất kỳ lý do tốt để sử dụng, tìm hiểu hoặc đề xuất XSLT không? [đóng cửa]

Tôi là một nhà phát triển trong 8 năm qua. Chúng tôi đã sử dụng XSLT chủ yếu để chuyển đổi XML thành HTML. Chúng tôi cũng đã sử dụng nó để chuyển đổi XML sang XML.

Nhưng chúng tôi đã thay thế cho tất cả mọi thứ bây giờ. HTML có thể được tạo thoải mái thông qua các ngôn ngữ lập trình như ASP.Net. XML có thể được đọc và điều khiển bằng bất kỳ ngôn ngữ highlevel tiêu chuẩn nào. Vì lập trình trong XSLT hơi phức tạp, bất kỳ ai cũng thích làm việc với các ngôn ngữ lập trình mới nhất.

Bây giờ câu hỏi của tôi: XSLT sẽ là một lựa chọn quan trọng trong tương lai, không xem xét thực tế về việc duy trì XSLT đã phát triển? Tôi có thể giới thiệu các lập trình viên mới học XSLT không?

Có một số trường hợp quan trọng trong đó XSLT có thể là một lựa chọn tốt:

• Trong một số trường hợp , phần mềm ETL ( Extract, Transform, Load ) có thể sử dụng XSLT. Ví dụ, nó có thể là một lựa chọn tốt khi cả dữ liệu được trích xuất và dữ liệu cần tải đều ở định dạng XML và trong đó biến đổi có thể được thay đổi mà không cần biên dịch lại ứng dụng.

• Một số ứng dụng lưu trữ dữ liệu trong XML sử dụng XSLT để trình bày dữ liệu này theo định dạng có thể đọc được của con người¹. Ví dụ: Windows Live Messenger lưu trữ dấu vết của các thông báo dưới dạng XML, nhưng khi bạn mở lịch sử trong chính WLM, nó sẽ hiển thị cho bạn một bảng đẹp mà thực tế là HTML được xây dựng thông qua XSLT.

• Một số trang web hướng đến nhà phát triển hoặc hướng dữ liệu có thể muốn cấp quyền truy cập vào XML nếu mục đích là sử dụng các trang của trang web theo lập trình². Nó tốt hơn bằng cách sử dụng các trình phân tích cú pháp HTML, đặc biệt là vì mã HTML có thể được thay đổi bất cứ lúc nào.

• XSLT, khi được sử dụng trong các trang web, cho phép phân tách chặt chẽ giữa HTML và mã phía sau, cho phép thuê một nhà phát triển cho mã phía sau và một nhà phát triển khác cho các công cụ HTML / CSS. Xem điểm 1 trong câu trả lời của tôi cho câu hỏi khác .

XSLT sẽ là một lựa chọn quan trọng trong tương lai? Chà, hôm nay không phải là một lựa chọn đáng kể và tôi nghi ngờ việc sử dụng XSLT sẽ tăng theo thời gian. Tôi bỏ qua lý do đó, nhưng nhiều nhà phát triển không thích XML và ghét XSLT.

Bạn có thể giới thiệu các lập trình viên mới học XSLT không? Chắc chắn rồi! Không chỉ XSLT có thể được sử dụng trong một số trường hợp khi các cách tiếp cận khác sẽ khó khăn hơn, mà XSLT cũng có một cách tiếp cận rất cụ thể mà các ngôn ngữ khác không có.

^{Điều này có nghĩa là XML không thực sự dễ đọc với con người: nếu bạn yêu cầu một người không làm việc trong CNTT đọc XML, anh ta sẽ rất kinh hoàng.
² Tôi biết có các dịch vụ web. Nhưng đôi khi, thật dễ dàng và đơn giản hơn, trên mỗi trang, để xây dựng một đối tượng động, sau đó để tuần tự hóa nó thành XML, sau đó, chuyển đổi nó thành HTML thông qua XSLT hoặc để bot truy cập trực tiếp vào XML.}

XSLT đã chết khá nhiều vì chỉ một số người đam mê vẫn sử dụng nó. Tuy nhiên, không có sự thay thế thực sự cho nó. Nếu bạn chỉ tập trung vào một trường hợp sử dụng duy nhất, chẳng hạn như kết xuất các trang HTML từ các tài liệu ngữ nghĩa, bạn sẽ tìm thấy các công cụ tốt hơn. Nếu bạn tìm kiếm các công cụ tạo mẫu mã, một lần nữa có các công cụ tốt hơn. Tương tự cho việc chuyển đổi tài liệu.

Nhưng nếu bạn tìm kiếm một công cụ hỗ trợ tất cả các trường hợp sử dụng này khá tốt trên tất cả các nền tảng, thì các lựa chọn sẽ rất hạn chế. Nếu bạn đã có một tài liệu XML và sẽ phải chuyển đổi nó thành một thứ gì đó để có thể sử dụng công cụ của bạn, có lẽ bạn nên xử lý dữ liệu của mình bằng XSLT (hoặc XQuery).

Dù bằng cách nào, bạn có thể học XSLT trong vài ngày, có thể vài tuần. Nó sẽ không làm tổn thương bạn để làm một kinh nghiệm đầu tay. Chỉ cần cho nó một shot. Ít nhất là đáng để nỗ lực lưu trữ loại mô hình này (các phép biến đổi dựa trên quy tắc) trong đầu của bạn để sử dụng sau này. Điều này một mình biện minh cho việc học XSLT.

Hmm Tôi tự hỏi nếu các API cấp cao tạo HTML từ mã sử dụng bất kỳ XSLT nào "dưới mui xe" ...

XSLT được sử dụng rộng rãi trong đó tôi làm việc để chuyển đổi XML từ một định dạng nguồn sang nhiều định dạng khác. Nó cũng có thể được sử dụng để chuyển đổi XML thành đầu ra không phải là XML. Tôi đã không làm nhiều điều này nhưng tôi đã nghe nói về nó được thực hiện để nhắm mục tiêu PDF và PostScript, trong số những người khác.

Vâng.

Hãy lấy một ví dụ điển hình: báo cáo thử nghiệm đơn vị trong tích hợp liên tục. Hầu hết các chương trình kiểm tra đơn vị và bao trùm mã chỉ đơn giản là xuất ra hàng tấn XML không thể đọc được. Nhưng với một vài XSLT đơn giản, bạn có thể tạo một tá báo cáo hữu ích từ cùng một dữ liệu. Và những người khác có thể sử dụng lại các báo cáo.

Bây giờ bạn có thể viết chúng bằng bất kỳ ngôn ngữ nào mà công cụ CI sử dụng cho các plugin, nhưng nếu bạn không biết ngôn ngữ đó (giả sử bạn là nhà phát triển .NET, sử dụng Jenkins) thì không cần phải học nó. Chỉ cần sử dụng một plugin đã áp dụng XSLT cho tệp XML và viết một số XSLT hữu ích.

Sẽ luôn có sự lựa chọn và đa dạng trong các ngôn ngữ lập trình, và lý do tại sao một người được chọn ưu tiên cho người khác cũng có liên quan nhiều đến sự quen thuộc và thời trang như với các tiêu chí khách quan như chức năng, năng suất và hiệu suất. Không ai có thể dự đoán thời trang, vì vậy không ai có thể dự đoán xu hướng trong tương lai của ngôn ngữ lập trình. Nhưng có rất nhiều người đã vượt qua các rào cản học tập ban đầu cho XSLT và thấy rằng nó là một công cụ cực kỳ năng suất cho rất nhiều nhiệm vụ (có thể là một phạm vi rộng hơn so với trước đây được thiết kế để giải quyết).

Đối với nhiều tác vụ tôi thấy XSLT đang được sử dụng cho (và các tác vụ tôi sử dụng cho bản thân mình), viết mã Java hoặc ASP để thực hiện công việc sẽ gây lãng phí cho ngân sách của chủ nhân. Nhưng có lẽ là không, nếu bạn tình cờ viết Java và viết kém XSLT.

XSLT không thể đọc được. Thông tin meta (các thẻ) chiếm quá nhiều so với thông tin thực (văn bản, yêu cầu xpath). Một mã tốt sẽ trông giống như một tài liệu và đây không phải là trường hợp của XSLT. Nó là một định dạng bền vững tốt cho các công cụ bản đồ.

Một ngôn ngữ chuyển đổi tốt sẽ cho phép xem trước kết quả chuyển đổi và xem luồng chuyển đổi (IF, ELSE, FOR, WHILE) cùng một lúc. điều này rất quan trọng đối với khả năng bảo trì Về khía cạnh này Velocity hoặc GenearateXY tốt hơn XSLT. GenerateXY thậm chí còn tốt hơn một chút vì nó phân tách luồng xem trước và luồng trong khi với Velocity, bạn sẽ không may phá vỡ thụt lề xem trước để cung cấp luồng có thể đọc được.

Điểm tốt duy nhất trong XSLT là nó quan tâm đến tính mô đun bằng cách sử dụng và thậm chí lạm dụng các phần tử "xsl: template". Vấn đề với điều này là nó tốt cho ngôn ngữ xử lý dữ liệu (Java, C, ...) nhưng rất phụ cho ngôn ngữ trình bày.

Thật

Một cái gì đó có thể sẽ thay thế XSLT một ngày nào đó vì nó hơi cồng kềnh để tìm hiểu và sử dụng. Tuy nhiên, hiện tại không có ngôn ngữ mẫu / ngôn ngữ chuyển đổi nào có thể linh hoạt và "thuần túy" trong quá trình triển khai.

XSL-T có thể được sử dụng cho một vài mục đích khác nhau:

• Bạn có thể "tạo" nội dung theo định dạng HTML từ dữ liệu bằng mẫu
• Bạn có thể chuyển đổi từ định dạng xml này sang định dạng khác
• Bạn có thể thao tác xml sang định dạng khác, có thể hiển thị một tập hợp con

Về cơ bản, tất cả những thứ này đều giống nhau, tuy nhiên, việc chuyển đổi một tệp dữ liệu XML này sang tệp khác. Bây giờ hãy xem xét một số công cụ khác nhau mà chúng ta có thể sử dụng thay vì XSLT.

Nếu chúng ta muốn thao túng nội dung của một trang XHTML, chúng ta có thể sử dụng regrec, nhưng regrec thì lộn xộn cho các công cụ cấu trúc. Nó tỏa sáng để thao tác các chuỗi nhưng tôi sẽ không sử dụng nó để tạo một bảng mục lục cho một cái gì đó hoặc trình bày nó trong một bố cục khác.

Tiếp theo là ASP.Net. Chúng tôi đặt bố cục của chúng tôi trong trang asp của chúng tôi và chèn một số mã phía sau cho các phần động. Một cách khác là từ bỏ phần bố trí và tạo mọi thứ từ cơ sở dữ liệu và sử dụng C # tạo đầu ra mong muốn của chúng tôi.

Vấn đề với cách tiếp cận đầu tiên là việc vụng về từ dữ liệu mô tả đến nội dung thực tế là vụng về. Nếu bạn có một số tệp dữ liệu chứa số điện thoại mà bạn muốn trình bày với các tiêu đề cho mỗi chữ cái, hãy hiển thị tổng số nr mục nhập, v.v. bạn phải có một số bố cục trong tệp bố cục và một số trong mã bạn đang tạo . Một tùy chọn khác là sử dụng một số dạng lưới web, tôi thấy chúng khá lộn xộn và đột nhiên bạn phải tìm hiểu cách thức hoạt động của lưới điện tử khi tất cả những gì bạn muốn làm là xuất ra một số html cụ thể được cung cấp dữ liệu.

Hoàn toàn năng động chắc chắn là một lựa chọn nhưng điều đó cũng khá vụng về. Ngay cả trong trường hợp tốt nhất khi bạn đang sử dụng thứ gì đó như LINQ, bạn sẽ phải xen kẽ mã lập trình với đầu ra theo cách khá xấu xí. Ngoài ra, không có cách nào tốt để xử lý đúng cách nội dung kiểu đệ quy không cấu trúc mà html thường là.

Với XSLT, bạn chỉ có thể tạo một mẫu cho một thẻ nhất định, giống như hoặc trong bối cảnh của nó, vì vậy nó được hiển thị khác đi nếu ví dụ đó là ngoặc đơn bởi một thứ khác.

Một câu trả lời lan man khá dài nhưng vâng, tôi nghĩ rằng có một giá trị lớn trong ngôn ngữ mẫu mô tả và XSLT là câu trả lời chuẩn nhất và tốt nhất mà chúng tôi có được cho đến nay.

Thất bại lớn nhất của XSLT là không có khả năng (trong bất kỳ triển khai thực tế nào) để giảm thiểu lượng tài liệu cần lưu giữ trong bộ nhớ tại một thời điểm để xử lý hiệu quả. Thay vào đó, toàn bộ tài liệu được đọc thành một số dạng biểu diễn và xử lý DOM được thực hiện theo cách đó. Nếu tài liệu rất lớn, thì các yêu cầu về bộ nhớ cũng vậy. Tuy nhiên, nhiều biểu định kiểu rõ ràng chỉ cần thẻ hiện tại và một số khác, ví dụ như tổ tiên của thẻ, tại bất kỳ thời điểm nào và do đó có thể được xử lý với bộ nhớ tối thiểu và truyền phát hiệu quả.

Vâng, về mặt ngôn ngữ thì thật kỳ lạ, nhưng đó chỉ là rào cản gia nhập. Nếu bạn biết XSLT, nó thường dễ hơn các lựa chọn thay thế - nhưng nếu bạn sẽ có các tài liệu lớn (hoặc nhiều tài liệu được xử lý cùng một lúc) thì tác động bộ nhớ của XSLT thường buộc các giải pháp thay thế khác tốn nhiều thời gian hơn.

Như một vấn đề thực tế, tôi nghĩ sử dụng XSL hiệu quả hơn so với ngôn ngữ khác để trình bày dữ liệu. Ví dụ: bạn có thể trình bày XML dưới dạng PDF bằng XSL-FO và bạn có thể kiểm soát từng inch, nhưng nếu bạn làm việc với RDLC (.NET), bạn sẽ thấy rất khó để trình bày chính xác những gì bạn muốn.

Ngay cả quá trình tiến hóa / hiệu chỉnh cũng khá dễ dàng, vì trong XSL, mỗi phần tử có mẫu riêng. Tôi nghĩ rằng phần mở rộng của XSL quan trọng hơn như XSLT và XSL-FO. Đó là lý do tại sao ngôn ngữ này vẫn sẽ được sử dụng trong tương lai (nhưng tôi thực sự hy vọng nó sẽ ổn định hơn và ít phức tạp hơn).

Tôi làm việc cho một công ty tích hợp dữ liệu và chúng tôi sử dụng XSLT với các công cụ độc quyền của chúng tôi như một giải pháp tuyệt vời liên quan đến XML sang HTML / XML / Ascii.