XSLT có đáng không? [đóng cửa]

Một thời gian trước, tôi đã bắt đầu một dự án trong đó tôi thiết kế một lược đồ XML html-esque để các tác giả có thể viết nội dung của họ (tài liệu khóa học giáo dục) ở định dạng đơn giản, sau đó sẽ được chuyển đổi thành HTML thông qua XSLT. Tôi đã chơi xung quanh (vật lộn) với nó một thời gian và đạt đến mức rất cơ bản nhưng sau đó quá khó chịu vì những hạn chế mà tôi đang gặp phải (có thể đó là những hạn chế về kiến ​​thức của tôi) và khi tôi đọc một blog đề xuất bỏ qua XSLT và chỉ cần viết trình phân tích cú pháp XML thành bất kỳ thứ gì của riêng bạn bằng ngôn ngữ bạn chọn, tôi háo hức nhảy vào điều đó và nó hoạt động rất xuất sắc.

Tôi vẫn đang nghiên cứu nó cho đến ngày nay ( tôi thực sự phải làm việc trên nó ngay bây giờ, thay vì chơi trên SO ), và tôi ngày càng thấy nhiều thứ hơn khiến tôi nghĩ rằng quyết định bỏ XSLT là một cái tốt.

Tôi biết rằng XSLT có vị trí của nó, ở chỗ nó là một tiêu chuẩn được chấp nhận và nếu mọi người đều viết thông dịch viên của riêng mình, thì 90% trong số họ sẽ kết thúc với TheDailyWTF . Nhưng vì nó là một ngôn ngữ kiểu chức năng thay vì kiểu thủ tục mà hầu hết các lập trình viên quen thuộc, đối với một người bắt tay vào một dự án như của riêng tôi, bạn có khuyên họ nên đi theo con đường mà tôi đã làm hay gắn bó với XSLT ?

Ưu điểm của XSLT:

• Miền dành riêng cho XML, vì vậy, chẳng hạn như không cần trích dẫn XML theo nghĩa đen trong đầu ra.
• Hỗ trợ XPath / XQuery, có thể là một cách hay để truy vấn DOM, giống như cách mà biểu thức chính quy có thể là một cách hay để truy vấn chuỗi.
• Ngôn ngữ chức năng.

Nhược điểm của XSLT:

• Có thể dài dòng một cách tục tĩu - bạn không cần phải trích dẫn XML theo nghĩa đen, điều đó có nghĩa là bạn phải trích dẫn mã. Và không phải theo một cách đẹp. Nhưng một lần nữa, nó không tệ hơn nhiều so với SSI thông thường của bạn.
• Không làm những điều nhất định mà hầu hết các lập trình viên đều cho là đương nhiên. Ví dụ, thao tác chuỗi có thể là một việc vặt. Điều này có thể dẫn đến "những khoảnh khắc đáng tiếc" khi những người mới thiết kế mã, sau đó điên cuồng tìm kiếm trên web các gợi ý về cách triển khai các chức năng mà họ cho rằng sẽ chỉ ở đó và không cho mình thời gian để viết.
• Ngôn ngữ chức năng.

Nhân tiện, một cách để có được hành vi thủ tục là chuỗi nhiều phép biến đổi với nhau. Sau mỗi bước, bạn có một DOM hoàn toàn mới để làm việc, nó phản ánh những thay đổi trong bước đó. Một số bộ xử lý XSL có phần mở rộng để thực hiện hiệu quả việc này trong một lần chuyển đổi, nhưng tôi quên chi tiết.

Vì vậy, nếu mã của bạn chủ yếu là đầu ra và không có nhiều logic, XSLT có thể là một cách rất gọn gàng để diễn đạt nó. Nếu có nhiều logic, nhưng chủ yếu là các biểu mẫu được tích hợp sẵn trong XSLT (chọn tất cả các phần tử trông giống như blah và cho mỗi đầu ra một blah), thì đó có thể là một môi trường khá thân thiện. Nếu bạn luôn thích suy nghĩ XML-ishly, thì hãy thử dùng XSLT 2.

Nếu không, tôi muốn nói rằng nếu ngôn ngữ lập trình yêu thích của bạn có triển khai DOM tốt hỗ trợ XPath và cho phép bạn xây dựng tài liệu theo cách hữu ích, thì sẽ có ít lợi ích khi sử dụng XSLT. Các liên kết với libxml2 và gdome2 sẽ hoạt động tốt và không có gì phải xấu hổ khi gắn bó với các ngôn ngữ có mục đích chung mà bạn biết rõ.

Các trình phân tích cú pháp XML tự phát triển thường không hoàn chỉnh (trong trường hợp đó bạn sẽ đến một ngày nào đó) hoặc không nhỏ hơn nhiều so với thứ mà bạn có thể đã rời khỏi kệ (trong trường hợp đó, bạn có thể đang lãng phí thời gian của mình), và cho cho bạn bất kỳ cơ hội nào để giới thiệu các vấn đề bảo mật nghiêm trọng xung quanh đầu vào độc hại. Đừng viết một cái trừ khi bạn biết chính xác những gì bạn đạt được khi làm nó. Điều này không có nghĩa là bạn không thể viết trình phân tích cú pháp cho thứ gì đó đơn giản hơn XML làm định dạng đầu vào của bạn, nếu bạn không cần mọi thứ mà XML cung cấp.

Tiêu cực nhiều quá!

Tôi đã sử dụng XSLT được vài năm rồi và thực sự yêu thích nó. Điều quan trọng bạn phải nhận ra là nó không phải là một ngôn ngữ lập trình mà nó là một ngôn ngữ khuôn mẫu (và về mặt này, tôi thấy nó vượt trội hơn hẳn so với asp.net / nhổ).

XML là định dạng dữ liệu trên thực tế của phát triển web ngày nay, có thể là tệp cấu hình, dữ liệu thô hoặc trong bộ nhớ. XSLT và XPath cung cấp cho bạn một vô cùng mạnh mẽ và rất hiệu quả để chuyển đổi dữ liệu đó sang bất kỳ định dạng đầu ra nào mà bạn có thể thích, ngay lập tức cung cấp cho bạn khía cạnh MVC đó là tách bản trình bày khỏi dữ liệu.

Sau đó là các khả năng tiện ích: loại bỏ không gian tên, nhận ra các định nghĩa lược đồ khác nhau, hợp nhất tài liệu.

Nó phải được tốt hơn để đối phó với XSLT hơn phát triển riêng của phương pháp trong nhà của bạn. Ít nhất XSLT là một tiêu chuẩn và là thứ bạn có thể thuê, và nếu nó thực sự là một vấn đề đối với nhóm của bạn, nó rất tự nhiên sẽ cho phép bạn giữ hầu hết nhóm của mình làm việc chỉ với XML.

Một trường hợp sử dụng trong thế giới thực: Tôi vừa viết một ứng dụng xử lý tài liệu XML trong bộ nhớ trong toàn bộ hệ thống và chuyển đổi thành JSON, HTML hoặc XML theo yêu cầu của người dùng cuối. Tôi có một yêu cầu khá ngẫu nhiên để cung cấp dưới dạng dữ liệu Excel. Một đồng nghiệp cũ đã làm điều gì đó tương tự theo chương trình nhưng nó yêu cầu một mô-đun gồm một vài tệp lớp và máy chủ đã được cài đặt MS Office! Hóa ra Excel có XSD: chức năng mới với tác động tối thiểu đến mã cơ sở trong 3 giờ.

Cá nhân tôi nghĩ đó là một trong những điều rõ ràng nhất mà tôi gặp phải trong sự nghiệp của mình và tôi tin rằng tất cả các vấn đề rõ ràng của nó (gỡ lỗi, thao tác chuỗi, cấu trúc lập trình) là do sự hiểu biết thiếu sót của công cụ.

Rõ ràng, tôi thực sự tin rằng nó là "đáng giá".

Tôi phải thừa nhận một sự thiên vị ở đây vì tôi dạy XSLT để kiếm sống. Nhưng, nó có thể đáng để che đậy các lĩnh vực mà tôi thấy sinh viên của mình đang làm việc. Họ chia thành ba nhóm nói chung: xuất bản, ngân hàng và web.

Nhiều câu trả lời cho đến nay có thể được tóm tắt là "nó không tốt cho việc tạo trang web" hoặc "nó không giống với ngôn ngữ X". Nhiều nhân viên công nghệ trải qua sự nghiệp của họ mà không cần tiếp xúc với các ngôn ngữ chức năng / khai báo. Khi tôi đang giảng dạy, những người có kinh nghiệm về Java / VB / C / etc là những người có vấn đề với ngôn ngữ (biến là các biến theo nghĩa đại số chứ không phải lập trình thủ tục). Đó là câu trả lời của nhiều người ở đây - Tôi chưa bao giờ làm quen với Java nhưng tôi sẽ không bận tâm đến việc phê bình ngôn ngữ này vì điều đó.

Trong nhiều trường hợp, nó là một công cụ không phù hợp để tạo trang web - một ngôn ngữ lập trình có mục đích chung có thể tốt hơn. Tôi thường cần lấy các tài liệu XML rất lớn và trình bày chúng trên web; XSLT làm cho điều đó trở nên tầm thường. Các sinh viên mà tôi thấy trong không gian này có xu hướng xử lý các tập dữ liệu và trình bày chúng trên web. XSLT chắc chắn không phải là công cụ áp dụng duy nhất trong lĩnh vực này. Tuy nhiên, nhiều người trong số họ đang sử dụng DOM để thực hiện việc này và XSLT chắc chắn ít đau hơn.

Các sinh viên ngân hàng mà tôi thấy nói chung đều sử dụng hộp DataPower. Đây là một công cụ XML và nó được sử dụng để đặt giữa các dịch vụ 'nói' các phương ngữ XML khác nhau. Việc chuyển đổi từ ngôn ngữ XML này sang ngôn ngữ XML khác hầu như không hề nhỏ trong XSLT và số lượng sinh viên tham dự các khóa học của tôi về điều này đang tăng lên.

Nhóm sinh viên cuối cùng mà tôi nhìn thấy đến từ một nền xuất bản (như tôi). Những người này có xu hướng có rất nhiều tài liệu bằng XML (tin tôi đi, xuất bản như một ngành công nghiệp đang phát triển rất nhiều vào XML - xuất bản kỹ thuật đã có trong nhiều năm và xuất bản thương mại đang phát triển). Những tài liệu này cần được xử lý (bạn nên nhớ đến DocBook to ePub ở đây).

Một người nào đó ở trên đã nhận xét rằng các tập lệnh có xu hướng dưới 60 dòng hoặc chúng trở nên khó sử dụng. Nếu nó trở nên khó sử dụng, thì tỷ lệ cược là các lập trình viên đã không thực sự có ý tưởng - XSLT là một tư duy rất khác so với nhiều ngôn ngữ khác. Nếu bạn không có tư duy, nó sẽ không hoạt động.

Nó chắc chắn không phải là một ngôn ngữ sắp chết (số lượng công việc tôi nhận được cho tôi biết điều đó). Hiện tại, có một chút 'bế tắc' cho đến khi Microsoft hoàn thành (rất muộn) việc triển khai XSLT 2. Nhưng nó vẫn ở đó và dường như đang diễn ra mạnh mẽ theo quan điểm của tôi.

Chúng tôi sử dụng XSLT rộng rãi cho những thứ như tài liệu và làm cho một số cài đặt cấu hình phức tạp có thể sử dụng được cho người dùng.

Đối với tài liệu, chúng tôi sử dụng rất nhiều DocBook, là định dạng dựa trên XML. Điều này cho phép chúng tôi lưu trữ và quản lý tài liệu của mình bằng tất cả mã nguồn của chúng tôi, vì các tệp là văn bản thuần túy. Với XSLT, chúng tôi có thể dễ dàng xây dựng các định dạng tài liệu của riêng mình, cho phép chúng tôi vừa tự động tạo nội dung theo cách chung vừa làm cho nội dung dễ đọc hơn. Ví dụ: khi chúng tôi xuất bản các ghi chú phát hành, chúng tôi có thể tạo XML giống như sau:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

Và sau đó bằng cách sử dụng XSLT (chuyển đổi ở trên thành DocBook), chúng tôi kết thúc với các ghi chú phát hành đẹp (thường là PDF hoặc HTML) trong đó ID lỗi được tự động liên kết với trình theo dõi lỗi của chúng tôi, các lỗi được nhóm theo thành phần và định dạng của mọi thứ hoàn toàn nhất quán . Và XML ở trên có thể được tạo tự động bằng cách truy vấn trình theo dõi lỗi của chúng tôi về những gì đã thay đổi giữa các phiên bản.

Một điểm khác mà chúng tôi nhận thấy XSLT hữu ích thực sự nằm trong sản phẩm cốt lõi của chúng tôi. Đôi khi khi giao tiếp với các hệ thống của bên thứ ba, chúng ta cần xử lý dữ liệu bằng cách nào đó trong một trang HTML phức tạp. Phân tích cú pháp HTML là xấu, vì vậy chúng tôi cung cấp dữ liệu thông qua một cái gì đó như TagSoup(tạo ra các sự kiện SAX XML phù hợp, về cơ bản cho phép chúng tôi xử lý HTML như thể nó được viết đúng XML) và sau đó chúng tôi có thể chạy một số XSLT dựa trên nó, để biến dữ liệu thành một định dạng "ổn định đã biết" mà chúng tôi có thể thực sự làm việc với . Bằng cách tách biến đổi đó thành tệp XSLT, điều đó có nghĩa là nếu và khi định dạng HTML thay đổi, bản thân ứng dụng không cần phải được nâng cấp, thay vào đó, người dùng cuối chỉ có thể tự chỉnh sửa tệp XSLT hoặc chúng tôi có thể gửi e-mail chúng là tệp XSLT được cập nhật mà không cần nâng cấp toàn bộ hệ thống.

Tôi muốn nói rằng đối với các dự án web, có nhiều cách tốt hơn để xử lý mặt xem so với XSLT ngày nay, nhưng là một công nghệ chắc chắn có những cách sử dụng cho XSLT. Nó không phải là ngôn ngữ dễ sử dụng nhất trên thế giới, nhưng nó chắc chắn chưa chết, và theo quan điểm của tôi thì vẫn còn rất nhiều cách sử dụng tốt.

XSLT là một ví dụ về ngôn ngữ lập trình khai báo .

Các ví dụ khác về ngôn ngữ lập trình khai báo bao gồm biểu thức chính quy, Prolog và SQL. Tất cả những thứ này đều có tính biểu cảm cao và nhỏ gọn, và thường được thiết kế rất tốt và mạnh mẽ cho nhiệm vụ mà chúng được thiết kế.

Tuy nhiên, các nhà phát triển phần mềm thường ghét những ngôn ngữ như vậy, bởi vì chúng quá khác biệt so với các ngôn ngữ thủ tục hoặc OO chính thống hơn nên chúng rất khó học và gỡ lỗi. Bản chất nhỏ gọn của chúng nói chung làm cho nó rất dễ gây ra nhiều thiệt hại do vô tình.

Vì vậy, mặc dù XSLT là một cơ chế hiệu quả để hợp nhất dữ liệu vào bản trình bày, nhưng nó không thành công ở bộ phận dễ sử dụng. Tôi tin rằng đó là lý do tại sao nó chưa thực sự bắt kịp.

Tôi nhớ tất cả những lời thổi phồng xung quanh XSLT khi tiêu chuẩn này mới được phát hành. Tất cả sự phấn khích xung quanh việc có thể xây dựng toàn bộ giao diện người dùng HTML với một chuyển đổi 'đơn giản'.

Hãy đối mặt với nó, nó khó sử dụng, gần như không thể gỡ lỗi, thường chậm đến mức không thể chịu nổi. Kết quả cuối cùng gần như luôn luôn kỳ quặc và ít hơn lý tưởng.

Tôi sẽ sớm gặm nhấm chân của chính mình hơn là sử dụng XSLT trong khi có nhiều cách tốt hơn để làm mọi việc. Nó vẫn có những vị trí của nó, tốt cho các nhiệm vụ chuyển đổi đơn giản.

Tôi đã sử dụng XSLT (và cả XQuery) rộng rãi cho nhiều thứ khác nhau - để tạo mã C ++ như một phần của quá trình xây dựng, tạo tài liệu từ các nhận xét doc và trong một ứng dụng phải làm việc với XML nói chung và XHTML nói riêng. . Trình tạo mã đặc biệt vượt quá 10.000 dòng mã XSLT 2.0 trải rộng xung quanh khoảng một chục tệp riêng biệt (nó đã làm được rất nhiều thứ - tiêu đề cho máy khách, xóa proxy / sơ khai, trình bao bọc COM, trình bao bọc .NET, ORM - để đặt tên một số ít). Tôi đã kế thừa nó qua một người khác, người không thực sự hiểu ngôn ngữ tốt, và những phần cũ hơn do đó khá lộn xộn. Tuy nhiên, những thứ mới hơn mà chúng tôi đã viết hầu hết được giữ lành mạnh và dễ đọc, và tôi không nhớ lại bất kỳ vấn đề cụ thể nào để đạt được điều đó. Nó chắc chắn không khó hơn làm nó cho C ++.

Nói về các phiên bản, xử lý XSLT 2.0 chắc chắn giúp bạn tỉnh táo hơn, nhưng 1.0 vẫn ổn đối với các chuyển đổi đơn giản hơn. Trong thị trường ngách của nó, nó là một công cụ cực kỳ tiện dụng và năng suất bạn nhận được từ một số tính năng dành riêng cho miền cụ thể (quan trọng nhất là điều phối động thông qua đối sánh mẫu) khó có thể sánh bằng. Mặc dù nhận thức được tính từ ngữ trong cú pháp dựa trên XML của XSLT, điều tương tự trong LINQ sang XML (ngay cả trong VB với các ký tự XML) thường dài hơn vài lần. Tuy nhiên, khá thường xuyên, nó trở nên thất thường vì việc sử dụng XML không cần thiết trong một số trường hợp ngay từ đầu.

Tóm lại: nó là một công cụ cực kỳ hữu ích khi có trong hộp công cụ của một người, nhưng nó là một công cụ rất chuyên dụng, vì vậy nó sẽ tốt miễn là bạn sử dụng nó đúng cách và đúng mục đích. Tôi thực sự ước có một triển khai .NET gốc, thích hợp của XSLT 2.0.

Tôi sử dụng XSLT (vì thiếu giải pháp thay thế tốt hơn), nhưng không phải để trình bày, chỉ để chuyển đổi:

1. Tôi viết các phép biến đổi XSLT ngắn để thực hiện các chỉnh sửa hàng loạt trên các tệp maven pom.xml của chúng tôi.

2. Tôi đã viết một đường dẫn các phép biến đổi để tạo các Lược đồ XML từ XMI (Sơ đồ UML). Nó hoạt động được một thời gian, nhưng cuối cùng nó trở nên quá phức tạp và chúng tôi phải mang nó ra sau chuồng.

3. Tôi đã sử dụng các phép biến đổi để cấu trúc lại các Lược đồ XML.

4. Tôi đã giải quyết một số hạn chế trong XSLT bằng cách sử dụng nó để tạo XSLT nhằm thực hiện công việc thực sự. (Bạn đã bao giờ cố gắng viết một XSLT tạo ra kết quả đầu ra bằng cách sử dụng không gian tên chưa được biết đến cho đến thời gian chạy chưa?)

Tôi tiếp tục quay lại với nó vì nó làm tốt hơn công việc xử lý XML mà nó đang xử lý so với các cách tiếp cận khác mà tôi đã thử, những cách này dường như không cần thiết hoặc đơn giản là hiểu sai về XML. XSLT khó chịu, nhưng tôi thấy sử dụng Oxy có thể chịu được.

Điều đó nói rằng, tôi đang điều tra việc sử dụng Clojure (một ngôn ngữ ngọng) để thực hiện các biến đổi của XML, nhưng tôi vẫn chưa hiểu rõ liệu cách tiếp cận đó có mang lại lợi ích cho tôi hay không.

Cá nhân tôi đã sử dụng XSLT trong một bối cảnh hoàn toàn khác. Trò chơi máy tính mà tôi đang làm vào thời điểm đó đã sử dụng rất nhiều trang giao diện người dùng được xác định bằng XML. Trong một lần tái cấu trúc lớn ngay sau khi phát hành, chúng tôi muốn thay đổi cấu trúc của các tài liệu XML này. Chúng tôi đã làm cho định dạng đầu vào của trò chơi tuân theo một cấu trúc nhận biết lược đồ và tốt hơn nhiều.

XSLT dường như là sự lựa chọn hoàn hảo cho bản dịch này từ định dạng cũ -> Định dạng mới. Trong vòng hai tuần, tôi đã thực hiện chuyển đổi từ cũ sang mới cho hàng trăm trang của chúng tôi. Tôi cũng có thể sử dụng nó để trích xuất nhiều thông tin về bố cục của các trang giao diện người dùng của chúng tôi. Tôi đã tạo danh sách các thành phần được nhúng trong đó tương đối dễ dàng mà sau đó tôi sử dụng XSLT để viết vào các định nghĩa lược đồ của chúng tôi.

Ngoài ra, đến từ nền tảng C ++, nó là một ngôn ngữ rất vui và thú vị để thành thạo.

Tôi nghĩ rằng đó là một công cụ để dịch XML từ định dạng này sang định dạng khác, nó thật tuyệt vời. Tuy nhiên, đó không phải là cách duy nhất để xác định một thuật toán lấy XML làm đầu vào và đầu ra Cái gì đó . Nếu thuật toán của bạn đủ phức tạp, thực tế là đầu vào là XML sẽ trở nên không liên quan đến lựa chọn công cụ của bạn - tức là cuộn của riêng bạn bằng C ++ / Python / bất cứ thứ gì.

Đối với ví dụ cụ thể của bạn, tôi sẽ tưởng tượng ý tưởng tốt nhất là tạo XML-> chuyển đổi XML của riêng bạn tuân theo logic nghiệp vụ của bạn. Tiếp theo, viết một trình dịch XSLT chỉ biết về định dạng và không làm gì thông minh. Đó có thể là một mức trung bình tốt nhưng nó hoàn toàn phụ thuộc vào những gì bạn đang làm. Có trình dịch XSLT trên đầu ra giúp dễ dàng tạo các định dạng đầu ra thay thế hơn - có thể in được, cho điện thoại di động, v.v.

Vâng, tôi sử dụng nó rất nhiều. Bằng cách sử dụng các tệp xslt khác nhau, tôi có thể sử dụng cùng một nguồn XML để tạo nhiều tệp HTML đa giác (X) (trình bày cùng một dữ liệu theo các cách khác nhau), nguồn cấp dữ liệu RSS, nguồn cấp dữ liệu Atom, tệp trình mô tả RDF và phân đoạn của sơ đồ trang web .

Nó không phải là thuốc chữa bách bệnh. Có những thứ nó làm tốt, và những thứ nó không làm tốt, và giống như tất cả các khía cạnh khác của lập trình, tất cả là về việc sử dụng đúng công cụ cho đúng công việc. Đó là một công cụ rất đáng có trong hộp công cụ của bạn nhưng nó chỉ nên được sử dụng khi thích hợp.

Tôi chắc chắn sẽ khuyên bạn nên dùng nó. Đặc biệt nếu bạn đang sử dụng studio trực quan được tích hợp các công cụ chỉnh sửa, xem và gỡ lỗi cho XSLT.

Vâng, đó là một nỗi đau khi bạn đang học, nhưng phần lớn nỗi đau là phải làm với sự quen thuộc. Cơn đau sẽ giảm dần khi bạn học ngôn ngữ.

W3schools có hai bài báo có giá trị đặc biệt: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Tôi nhận thấy XSLT khá khó làm việc.

Tôi đã có kinh nghiệm làm việc trên một hệ thống hơi giống với hệ thống mà bạn mô tả. Công ty của tôi lưu ý rằng dữ liệu mà chúng tôi đang trả về từ "tầng giữa" là ở dạng XML và các trang sẽ được hiển thị bằng HTML có thể cũng là XHTML, ngoài ra họ đã nghe nói rằng XSL là một tiêu chuẩn để chuyển đổi giữa XML các định dạng. Vì vậy, các "kiến trúc sư" (ý tôi là những người có suy nghĩ thiết kế sâu sắc nhưng dường như không bao giờ viết mã) đã quyết định rằng tầng trước của chúng tôi sẽ được thực hiện bằng cách viết các tập lệnh XSLT để chuyển đổi dữ liệu thành XHTML để hiển thị.

Sự lựa chọn hóa ra là thảm họa. XSLT, hóa ra, là một nỗi đau khi viết. Và vì vậy tất cả các trang của chúng tôi đều khó viết và khó bảo trì. Chúng tôi sẽ làm tốt hơn nhiều nếu sử dụng JSP (đây là trong Java) hoặc một số phương pháp tương tự sử dụng một loại đánh dấu (dấu ngoặc nhọn) cho định dạng đầu ra (HTML) và một loại đánh dấu khác (như <% ... %>) cho siêu dữ liệu. Điều khó hiểu nhất về XSLT là nó được viết bằng XML, và nó dịch từ XML sang XML ... khá khó khăn để giữ cho tất cả 3 tài liệu XML khác nhau ngay lập tức.

Tình huống của bạn hơi khác một chút: thay vì viết từng trang trong XSLT như tôi đã làm, bạn chỉ cần viết MỘT bit mã trong XSLT (mã để chuyển đổi từ các mẫu sang hiển thị). Nhưng có vẻ như bạn có thể đã gặp phải khó khăn giống như tôi. Tôi muốn nói rằng cố gắng diễn giải một DSL đơn giản dựa trên XML (ngôn ngữ dành riêng cho miền) như bạn đang làm KHÔNG phải là một trong những điểm mạnh của XSLT. (Mặc dù nó CÓ THỂ thực hiện công việc ... sau cùng, nó đã hoàn thành Turing!)

Tuy nhiên, nếu những gì bạn có đơn giản hơn: bạn có dữ liệu ở một định dạng XML và muốn thực hiện các thay đổi đơn giản đối với nó - không phải là DSL mô tả trang đầy đủ, mà là một số sửa đổi đơn giản, thì XSLT là một công cụ tuyệt vời cho mục đích đó. Bản chất khai báo (không phải thủ tục) thực sự là một lợi thế cho mục đích đó.

- Michael Chermside

XSLT rất khó làm việc, nhưng một khi bạn chinh phục được nó, bạn sẽ hiểu rất kỹ về DOM và lược đồ. Nếu bạn cũng XPath, thì bạn đang trên đường học lập trình hàm và điều này sẽ tiếp xúc với các kỹ thuật và cách giải quyết vấn đề mới. Trong một số trường hợp, chuyển đổi liên tiếp có tác dụng mạnh hơn các giải pháp thủ tục.

Tôi sử dụng XSLT rộng rãi, cho giao diện người dùng kiểu MVC tùy chỉnh. Mô hình được "tuần tự hóa" thành xml (không qua xml serializaiton), và sau đó được chuyển đổi thành html thông qua xslt. Lợi thế so với ASP.NET nằm ở sự tích hợp tự nhiên với XPath và các yêu cầu khắt khe hơn về cấu trúc tài liệu trong xslt so với hầu hết các ngôn ngữ khác).

Thật không may, ngôn ngữ này có một số hạn chế (ví dụ: khả năng chuyển đổi đầu ra của một phép chuyển đổi khác), điều này có nghĩa là đôi khi làm việc với nó rất khó chịu.

Tuy nhiên, việc tách biệt các mối quan tâm mà nó cấp có thể đạt được một cách dễ dàng, được thực thi mạnh mẽ không phải là thứ mà tôi thấy một công nghệ khác cung cấp ngay bây giờ - vì vậy đối với chuyển đổi tài liệu, đó vẫn là thứ tôi khuyên dùng.

Tôi đã sử dụng XML, XSD và XSLT trong một dự án tích hợp giữa các hệ thống DB rất giống nhau vào năm 2004. Tôi đã phải học XSD và XSLT từ đầu nhưng không khó. Điều tuyệt vời về các công cụ này là nó cho phép tôi viết mã C ++ độc lập với dữ liệu, dựa vào XSD và XSLT để xác thực / xác minh và sau đó chuyển đổi các tài liệu XML. Thay đổi định dạng dữ liệu, thay đổi tài liệu XSD và XSLT không phải mã C ++ sử dụng các thư viện Xerces.

Đối với sự quan tâm: XSD chính là 150KB và kích thước trung bình của XSLT là <5KB IIRC.

Lợi ích tuyệt vời khác là XSD là một tài liệu đặc tả mà XSLT dựa trên. Hai người làm việc rất hòa hợp. Và thông số kỹ thuật rất hiếm trong phát triển phần mềm ngày nay.

Mặc dù tôi không gặp quá nhiều khó khăn khi học bản chất khai báo XSD và XSLT, nhưng tôi thấy rằng các lập trình viên C / C ++ khác đã gặp khó khăn lớn trong việc điều chỉnh theo cách khai báo. Khi họ thấy đó là nó, ah thủ tục họ lẩm bẩm, bây giờ tôi đã hiểu! Và họ đã tiến hành (chơi chữ?) Để viết XSLT theo thủ tục! Vấn đề là bạn phải học XPath và hiểu các trục của XML. Nhắc tôi về những lập trình viên C thời xưa đang điều chỉnh để sử dụng OO khi viết C ++.

Tôi đã sử dụng các công cụ này vì chúng cho phép tôi viết một cơ sở mã C ++ nhỏ được tách biệt khỏi tất cả, trừ phần cơ bản nhất của các sửa đổi cấu trúc dữ liệu và sau đó là các thay đổi cấu trúc DB. Mặc dù tôi thích C ++ hơn bất kỳ ngôn ngữ nào khác, tôi sẽ sử dụng những gì tôi cho là hữu ích để mang lại lợi ích cho khả năng tồn tại lâu dài của một dự án phần mềm.

Tôi từng nghĩ XSLT là một ý tưởng tuyệt vời. Ý tôi là nó là một ý tưởng tuyệt vời.

Trường hợp nó không thành công là thực hiện.

Vấn đề mà tôi phát hiện ra theo thời gian là các ngôn ngữ lập trình trong XML chỉ là một ý tưởng tồi. Nó làm cho toàn bộ điều không thể xuyên thủng. Cụ thể, tôi nghĩ XSLT rất khó học, viết mã và hiểu. XML trên đầu trang của các khía cạnh chức năng chỉ làm cho toàn bộ điều quá khó hiểu. Tôi đã cố gắng học nó khoảng 5 lần trong sự nghiệp của mình, và nó không thành công.

OK, bạn có thể 'công cụ' nó - tôi nghĩ đó một phần là do thiết kế của nó - nhưng đó là thất bại thứ hai: tất cả các công cụ XSLT trên thị trường, khá đơn giản là ... tào lao!

Đặc tả XSLT định nghĩa XSLT là "ngôn ngữ để chuyển đổi tài liệu XML thành các tài liệu XML khác". Nếu bạn đang cố gắng thực hiện bất kỳ điều gì nhưng xử lý dữ liệu cơ bản nhất trong XSLT thì có lẽ có các giải pháp tốt hơn.

Cũng cần lưu ý rằng khả năng xử lý dữ liệu của XSLT có thể được mở rộng trong .NET bằng cách sử dụng các chức năng mở rộng tùy chỉnh:

• Tài liệu MSDN
• CSharpBạn bè: Hướng dẫn

Tôi duy trì một hệ thống tài liệu trực tuyến cho công ty của tôi. Người viết tạo tài liệu bằng SGML (một ngôn ngữ giống như xml). SGML sau đó được kết hợp với XSLT và chuyển đổi thành HTML.

Điều này cho phép chúng tôi dễ dàng thực hiện các thay đổi đối với bố cục tài liệu mà không cần thực hiện bất kỳ mã hóa nào. Vấn đề chỉ là thay đổi XSLT.

Điều này hoạt động tốt cho chúng tôi. Trong trường hợp của chúng tôi, đó là tài liệu chỉ đọc. Người dùng không tương tác với tài liệu.

Ngoài ra, bằng cách sử dụng XSLT, bạn đang làm việc gần hơn với miền sự cố (HTML) của mình. Tôi luôn coi đó là một ý kiến ​​hay.

Cuối cùng, nếu hệ thống hiện tại của bạn HOẠT ĐỘNG, hãy để nó yên. Tôi sẽ không bao giờ đề nghị chuyển mã hiện có của bạn vào thùng rác. Nếu tôi bắt đầu từ đầu, tôi sẽ sử dụng XSLT, nhưng trong trường hợp của bạn, tôi sẽ sử dụng những gì bạn có.

Nó phụ thuộc vào những gì bạn cần nó cho. Điểm mạnh chính của nó là khả năng bảo trì dễ dàng của việc chuyển đổi và việc viết trình phân tích cú pháp của riêng bạn thường xóa bỏ điều đó. Như đã nói, đôi khi một hệ thống nhỏ và đơn giản và thực sự không cần một giải pháp "lạ mắt". Miễn là trình tạo dựa trên mã của bạn có thể thay thế được mà không cần phải thay đổi mã khác, không có vấn đề gì lớn.

Đối với sự xấu xí của XSL, vâng, nó xấu xí. Có, nó cần một số để làm quen. Nhưng một khi bạn hiểu nó (không mất nhiều thời gian IMO), nó thực sự thuận buồm xuôi gió. Theo kinh nghiệm của tôi, các biến đổi đã biên dịch chạy khá nhanh và bạn chắc chắn có thể gỡ lỗi chúng.

Tôi vẫn tin rằng XSLT có thể hữu ích nhưng nó là một ngôn ngữ xấu xí và có thể dẫn đến một mớ hỗn độn khủng khiếp khó đọc, không thể giải thích được. Một phần bởi vì con người không thể đọc được XML đủ để tạo nên một "ngôn ngữ" và một phần vì XSLT bị kẹt ở đâu đó giữa tính khai báo và thủ tục. Đã nói rằng, và tôi nghĩ rằng một phép so sánh có thể được rút ra với các biểu thức chính quy, nó có công dụng khi nói đến các vấn đề đơn giản được xác định rõ ràng.

Sử dụng cách tiếp cận thay thế và phân tích cú pháp XML trong mã có thể khó chịu như nhau và bạn thực sự muốn sử dụng một số loại công nghệ sắp xếp / liên kết XML (chẳng hạn như JiBX trong Java) sẽ chuyển đổi thẳng XML của bạn thành một đối tượng.

Nếu bạn có thể sử dụng XSLT theo kiểu khai báo (mặc dù tôi không hoàn toàn đồng ý rằng đó là ngôn ngữ khai báo) thì tôi nghĩ nó hữu ích và mang tính biểu cảm.

Tôi đã viết các ứng dụng web sử dụng ngôn ngữ OO (trong trường hợp của tôi là C #) để xử lý lớp dữ liệu / xử lý, nhưng xuất ra XML thay vì HTML. Sau đó, điều này có thể được khách hàng sử dụng trực tiếp dưới dạng API dữ liệu hoặc được XSLTs hiển thị dưới dạng HTML. Vì C # đang xuất ra XML tương thích về mặt cấu trúc với việc sử dụng này nên tất cả đều rất trơn tru và logic trình bày được giữ nguyên tính khai báo. Việc theo dõi và thay đổi dễ dàng hơn so với việc gửi các thẻ từ C #.

Tuy nhiên, khi bạn yêu cầu nhiều logic xử lý hơn ở cấp XSLT, nó trở nên phức tạp và dài dòng - ngay cả khi bạn "lấy" kiểu chức năng.

Tất nhiên, những ngày này, tôi có thể đã viết các ứng dụng web đó bằng giao diện RESTful - và tôi nghĩ rằng các "ngôn ngữ" dữ liệu như JSON đang đạt được sức hút trong các lĩnh vực mà XML đã được XSLT truyền thống biến đổi. Nhưng hiện tại XSLT vẫn là một công nghệ quan trọng và hữu ích.

Tôi đã dành nhiều thời gian cho XSLT và nhận thấy rằng mặc dù nó là một công cụ hữu ích trong một số trường hợp, nhưng chắc chắn nó không phải là một giải pháp sửa chữa tất cả. Nó hoạt động rất tốt cho các mục đích B2B khi nó được sử dụng để dịch dữ liệu cho đầu vào / đầu ra XML có thể đọc được bằng máy. Tôi không nghĩ rằng bạn đang đi sai hướng trong tuyên bố của bạn về những hạn chế của nó. Một trong những điều làm tôi thất vọng nhất là các sắc thái trong việc triển khai XSLT.

Có lẽ bạn nên xem xét một số ngôn ngữ đánh dấu khác có sẵn. Tôi tin rằng Jeff đã viết một bài báo về chủ đề này liên quan đến Stack Overflow.

HTML có phải là ngôn ngữ đánh dấu nhân đạo không?

Tôi sẽ xem qua những gì anh ấy đã viết. Bạn có thể tìm thấy một gói phần mềm thực hiện những gì bạn muốn "ngay từ đầu", hoặc ít nhất là rất gần gũi thay vì viết nội dung của riêng bạn từ đầu.

Tôi hiện đang được giao nhiệm vụ thu thập dữ liệu từ một trang web công cộng (vâng, tôi biết). Rất may, nó tuân theo xhtml nên tôi có thể sử dụng xslt để thu thập dữ liệu tôi cần. Dung dịch thu được có thể đọc được, sạch sẽ và dễ dàng thay đổi nếu cần. Hoàn hảo!

Tôi đã sử dụng XSLT trước đây. Nhóm 6 tệp .xslt (được cấu trúc lại từ một tệp lớn) dài khoảng 2750 dòng trước khi tôi viết lại nó bằng C #. Mã C # hiện có 4000 dòng chứa rất nhiều logic; Tôi thậm chí không muốn nghĩ về những gì sẽ cần để viết trong XSLT.

Điểm mà tôi đã từ bỏ là khi tôi nhận ra rằng không có XPATH 2.0 đã làm ảnh hưởng đáng kể đến sự tiến bộ của tôi.

Để trả lời ba câu hỏi của bạn:

1. Tôi đã sử dụng XSLT một lần cách đây vài năm.
2. Tôi tin rằng XSLT có thể là giải pháp phù hợp trong một số trường hợp nhất định. (Không bao giờ nói không bao giờ)
3. Tôi có xu hướng đồng ý với giả định của bạn rằng nó chủ yếu hữu ích cho các phép biến đổi 'đơn giản'. Nhưng tôi nghĩ rằng miễn là bạn hiểu rõ về XSLT, thì sẽ có trường hợp sử dụng nó cho các nhiệm vụ lớn hơn như xuất bản một trang web dưới dạng XML được chuyển đổi thành HTML.

Tôi tin rằng lý do nhiều nhà phát triển không thích XSLT là vì họ không hiểu mô hình khác nhau về cơ bản mà nó dựa trên. Nhưng với sự quan tâm gần đây đến lập trình hàm, chúng ta có thể thấy XSLT sẽ trở lại ...

Một nơi mà xslt thực sự tỏa sáng là tạo báo cáo. Tôi nhận thấy rằng quy trình gồm 2 bước, với bước đầu tiên xuất dữ liệu báo cáo dưới dạng tệp xml và bước thứ hai tạo báo cáo trực quan từ xml bằng xslt. Điều này cho phép các báo cáo trực quan đẹp mắt trong khi vẫn giữ dữ liệu thô xung quanh như một cơ chế xác nhận nếu cần.

Tại một công ty trước đây, chúng tôi đã làm rất nhiều với XML và XSLT. Cả XML và XSLT đều lớn.

Có, có một đường cong học tập, nhưng sau đó bạn có một công cụ mạnh mẽ để xử lý XML. Và bạn thậm chí có thể sử dụng XSLT trên XSLT (đôi khi có thể hữu ích).

Hiệu suất cũng là một vấn đề (với XML rất lớn) nhưng bạn có thể giải quyết vấn đề đó bằng cách sử dụng XSLT thông minh và thực hiện một số xử lý trước với XML (được tạo).

Bất kỳ ai có kiến ​​thức về XSLT đều có thể thay đổi diện mạo của thành phẩm vì nó không được biên dịch.

Cá nhân tôi thích XSLT và bạn có thể muốn cung cấp cú pháp đơn giản (không có mẫu rõ ràng, chỉ là một tệp HTML cũ thông thường với một vài thẻ XSLT để đưa giá trị vào đó), nhưng nó không dành cho tất cả mọi người.

Có thể bạn chỉ muốn cung cấp cho tác giả của mình một giao diện Wiki hoặc Markdown đơn giản. Cũng có các thư viện dành cho việc đó và nếu XSLT không hoạt động với bạn, có thể XML cũng không hoạt động với chúng.

XSLT không phải là phần cuối của phép biến đổi xml. Tuy nhiên, rất khó để đánh giá dựa trên thông tin được cung cấp nếu đó có phải là giải pháp tốt nhất cho vấn đề của bạn hay có các cách tiếp cận khác hiệu quả hơn và có thể bảo trì được hay không. Bạn nói rằng các tác giả có thể nhập nội dung của họ ở định dạng đơn giản - định dạng nào? Hộp văn bản? Bạn đang chuyển đổi nó thành loại html nào? Để đánh giá liệu XSLT có phải là công cụ phù hợp cho công việc hay không, bạn nên biết chi tiết hơn về các tính năng của sự chuyển đổi này.

Tôi chỉ thích sử dụng XSLT để thay đổi cấu trúc cây của tài liệu XML. Tôi thấy thật cồng kềnh khi làm bất cứ điều gì liên quan đến xử lý văn bản và chuyển điều đó thành một tập lệnh tùy chỉnh mà tôi có thể chạy trước hoặc sau khi áp dụng XSLT cho tài liệu XML.

XSLT 2.0 bao gồm nhiều hàm chuỗi hơn, nhưng tôi nghĩ rằng nó không phù hợp với ngôn ngữ và không có nhiều triển khai XSLT 2.0.