it-swarm-vi.tech

XSLT có đáng không?

Cách đây một thời gian, tôi đã bắt đầu một dự án nơi 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) theo định dạng đơn giản mà 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á bực mình vì những hạn chế mà tôi 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 gợi ý bỏ qua XSLT và chỉ cần viết trình phân tích cú pháp XML của riêng bạn sang ngôn ngữ bạn chọn, tôi háo hức nhảy vào đó và nó đã hoạt động rất tốt.

Tôi vẫn đang làm việc cho đến ngày hôm nay ( Tôi thực sự phải làm việc với nó ngay bây giờ, thay vì chơi trên SO), và tôi đang thấy ngày càng nhiều thứ tạo ra Tôi nghĩ rằng quyết định bỏ XSLT là một quyết định 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 viết thông dịch viên của riêng họ, 90% trong số họ sẽ kết thúc vào TheDailyWTF . Nhưng cho rằng đó là 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, vì ai đó bắt tay vào một dự án như của riêng tôi, bạn sẽ khuyên họ nên đi theo con đường mà tôi đã làm, hoặc sử dụng XSLT ?

111
nickf

Ưu điểm của XSLT:

  • Tên miền cụ thể cho XML, vì vậy, ví dụ không cần trích dẫn XML bằng chữ trong đầu ra.
  • Hỗ trợ XPath/XQuery, có thể là một cách hay để truy vấn DOM, giống như cách các biểu thức thông thường 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ể rất dài dòng - 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ã một cách hiệu quả. Và không phải trong 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 một số điều nhất định mà hầu hết các lập trình viên coi 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 không may" khi người mới thiết kế mã, sau đó điên cuồng tìm kiếm trên web để tìm gợi ý về cách thực hiện các chức năng mà họ cho là sẽ ở đó 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à xâu chuỗi nhiều biến đổi lạ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, phản ánh những thay đổi trong bước đó. Một số bộ xử lý XSL có các phần mở rộng để thực hiện điều này một cách hiệu quả trong một biến đổi, nhưng tôi quên các 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 để thể hiện nó. Nếu có nhiều logic, nhưng chủ yếu là các biểu mẫu được tích hợp trong XSLT (chọn tất cả các yếu tố trông giống như blah và với mỗi đầu ra blah), đó có thể là một môi trường khá thân thiện. Nếu bạn thích nghĩ về XML-ishly mọi lúc, thì hãy thử XSLT 2.

Mặt khác, 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ì có rất ít lợi ích khi sử dụng XSLT. Các ràng buộc với libxml2 và gdome2 sẽ hoạt động tốt và không có gì xấu hổ khi sử dụng 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 được trồng tại nhà thường không đầy đủ (trong trường hợp đó bạn sẽ tháo gỡ một ngày nào đó) hoặc khác không nhỏ hơn nhiều so với những gì bạn có thể đã lấy ra khỏi kệ (trong trường hợp đó bạn có thể lãng phí thời gian của mình) và đưa ra bạn có 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 bằng cách làm nó. Điều đó không có nghĩa là bạn không thể viết một trình phân tích cú pháp cho một cái gì đó đơn giản hơn XML như đị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.

63
Steve Jessop

Quá nhiều tiêu cực!

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 mà bạn phải nhận ra là nó không phải là ngôn ngữ lập trình mà là ngôn ngữ tạo khuôn mẫ (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 thực tế của phát triển web ngày nay, có thể là các tệp cấu hình, dữ liệu thô hoặc trong bộ nhớ lặp lại. XSLT và XPath cung cấp cho bạn một cách rất lớn cách mạnh mẽ và rất hiệu quả để chuyển đổi dữ liệu đó thành bất kỳ định dạng đầu ra nào bạn muốn, ngay lập tức cung cấp cho bạn khía cạnh MVC của việc tách bản trình bày khỏi dữ liệu.

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

phải sẽ tốt hơn để đối phó với XSLT hơn là phát triển các phương thức nội bộ của riêng bạn. Ít nhất XSLT là một tiêu chuẩn và một cái gì đó 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 thì chính bản chất của nó sẽ cho phép bạn giữ cho hầu hết nhóm của bạn làm việc chỉ với XML.

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ý các tài liệu XML trong bộ nhớ trên toàn 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 một cái gì đó tương tự theo chương trình nhưng nó yêu cầu một mô-đun của một vài tệp lớp và máy chủ đã cài đặt MS Office! Hóa ra Excel có XSD: chức năng mới với tác động mã cơ sở tối thiểu trong 3 giờ.

Cá nhân tôi nghĩ rằng đó là một trong những điều sạch nhất 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 (gỡ lỗi, thao tác chuỗi, cấu trúc lập trình) đều không hiểu rõ về công cụ này.

Rõ ràng, tôi tin tưởng mạnh mẽ rằng nó "đáng giá".

88
annakata

Tôi phải thừa nhận một thành kiến ​​ở đây vì tôi dạy XSLT để kiếm sống. Nhưng, nó có thể có giá trị bao trùm các lĩnh vực mà tôi thấy các 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à "không tốt khi tạo trang web" hoặc "không có gì giống ngôn ngữ X". Nhiều người công nghệ trải qua sự nghiệp của họ mà không 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, dân gian Java/VB/C/etc có kinh nghiệm là những người có vấn đề với ngôn ngữ (các biến là các biến theo nghĩa đại số không phải là lập trình thủ tục chẳng hạn). Đó là nhiều người trả lời ở đây - Tôi chưa bao giờ hiểu được Java nhưng tôi sẽ không bận tâm phê bình ngôn ngữ vì điều đó.

Trong nhiều trường hợp, đây là một công cụ không phù hợp để tạo trang web - ngôn ngữ lập trình cho 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 tầm thường đó. Các sinh viên tôi thấy trong không gian này có xu hướng xử lý các bộ 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 không gian này. Tuy nhiên, nhiều người trong số họ đang sử dụng DOM để làm điều này và XSLT chắc chắn ít đau đớn hơn.

Các sinh viên ngân hàng mà tôi thấy sử dụng hộp DataPower nói chung. Đây là một thiết bị XML và nó được sử dụng để ngồi giữa các phương ngữ XML khác nhau của các dịch vụ. Chuyển đổi từ ngôn ngữ XML này sang ngôn ngữ khác gần như không đáng kể trong XSLT và số lượng sinh viên tham gia 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 tôi thấy đến từ một nền tảng xuất bản (như tôi). Những người này có xu hướng có các tài liệu khổng lồ về XML (tin tôi đi, xuất bản như một ngành công nghiệp đang thâm nhập 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 đến đó bây giờ). Các tài liệu này cần được xử lý (DocBook to ePub xuất hiện ở đây).

Một số người ở 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, tỷ lệ cược là người viết mã chưa thực sự có ý tưởng - XSLT là một tư duy rất khác với nhiều ngôn ngữ khác. Nếu bạn không có suy nghĩ thì nó sẽ không hoạt động.

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

27
Nic Gibson

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.

Đối với tài liệu, chúng tôi sử dụng rất nhiều DocBook, đây 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 chúng tôi với tất cả cá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 tự động tạo nội dung theo cách chung và 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 trông giống như:

<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 từ trên thành DocBook), chúng tôi kết thúc với các ghi chú phát hành Nice (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 phù hợp . 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 để biết những gì đã thay đổi giữa các phiên bản.

Một nơi khác mà chúng tôi đã tìm thấy XSLT là hữu ích thực sự là 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 rất tệ, 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 thích 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 chống lại nó, để biến dữ liệu thành định dạng "ổn định đã biết" mà chúng ta thực sự có thể làm việc với. Bằng cách tách biệt chuyể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 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 email chúng là một tệp XSLT được cập nhật mà không cần phải nâng cấp toàn bộ hệ thống.

Tôi có thể nói rằng đối với các dự án web, có nhiều cách tốt hơn để xử lý phía xem so với XSLT ngày nay, nhưng là một công nghệ chắc chắn có 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 không chết và theo quan điểm của tôi vẫn có rất nhiều công dụng tốt.

24
Adam Batkin

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 các biểu thức chính quy, Prolog và SQL. Tất cả đề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 các ngôn ngữ như vậy, vì chúng quá khác biệt so với các ngôn ngữ chính hơn OO hoặc các ngôn ngữ thủ tục mà chúng khó học và gỡ lỗi. vô số thiệt hại vô tình.

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

19
Bill Karwin

Tôi nhớ tất cả sự cường điệu xung quanh XSLT khi tiêu chuẩn 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 biến đổi 'đơn giản'.

Hãy để đối mặt với nó, nó rất khó sử dụng, gần như không thể gỡ lỗi, thường chậm không 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 chân 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. Tuy nhiên, nó có vị trí của nó, tốt cho các nhiệm vụ biến đổi đơn giản.

12
Crusty

Tôi đã sử dụng rộng rãi XSLT (và cả XQuery) 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 tài liệu 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 rất nhiều . Công cụ tạo mã đặc biệt vượt quá 10.000 dòng mã XSLT 2.0 trải rộng khoảng một chục tệp riêng biệt (nó đã làm rất nhiều thứ - tiêu đề cho máy khách, từ xa proxy/sơ khai, trình bao bọc COM, trình bao bọc .NET, ORM - để đặt tên một vài) Tôi đã thừa hưởng nó qua một người đàn ông khác, những người không thực sự hiểu ngôn ngữ tốt, và do đó, các bit cũ hơn là một mớ hỗn độn. Tuy nhiên, những thứ mới hơn mà chúng tôi đã viết hầu hết được giữ nguyên và có thể đọc được, và tôi không nhớ bất kỳ vấn đề cụ thể nào khi đạt được điều đó. Nó chắc chắn không khó hơn làm 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, nhưng 1.0 vẫn ổn cho các biến đổi đơn giản hơn. Trong lĩnh vực của nó, nó là một công cụ cực kỳ tiện dụng và năng suất bạn có được từ các tính năng cụ thể của tên miền (quan trọng nhất là công văn động thông qua khớp mẫu) rất khó để so sánh. Mặc dù nhận thức rõ ràng về cú pháp dựa trên XML của XSLT, nhưng điều tương tự trong LINQ to XML (ngay cả trong VB với các chữ XML) thường dài hơn nhiều lần. Tuy nhiên, nó thường bị lỗi do việc sử dụng XML không cần thiết trong một số trường hợp ở nơi đầu tiên.

Tóm lại: nó là một công cụ cực kỳ hữu ích để 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ó tốt miễn là bạn sử dụng đúng cách và đúng mục đích của nó. Tôi thực sự muốn có một triển khai .NET thích hợp, nguyên bản của XSLT 2.0.

10
Pavel Minaev

Tôi sử dụng XSLT (vì thiếu sự 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 lúc, nhưng cuối cùng nó đã quá phức tạp và chúng tôi phải đưa nó ra đằng sau chuồng ngựa.

  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 đã khắc phục một số hạn chế trong XSLT bằng cách sử dụng nó để tạo XSLT để thực hiện công việc thực sự. (Bạn đã bao giờ thử viết XSLT tạo đầu ra bằng cách sử dụng các không gian tên cho đến khi chạy chưa?)

Tôi tiếp tục quay lại với nó bởi vì nó thực hiện công việc tốt hơn trong 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ử, dường như không cần mất hoặc đơn giản là hiểu nhầm XML. XSLT là khó chịu, nhưng tôi thấy việc sử dụng Oxygen làm cho nó có thể chịu được.

Điều đó nói rằng, tôi đang điều tra bằng cách sử dụng Clojure (LISP) để thực hiện các phép biến đổi XML, nhưng tôi chưa đủ xa để biết liệu cách tiếp cận đó có mang lại lợi ích cho tôi không.

9
bendin

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 việc tại thời điểm đó đã sử dụng hàng tấn trang UI được xác định bằng XML. Trong một lần tái cấu trúc chính 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 cấu trúc nhận biết lược đồ 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 đã 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ề cách bố trí các trang UI của chúng tôi. Tôi đã tạo các 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 thú vị và thú vị để làm chủ.

Tôi nghĩ rằng với tư cách 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, đây không phải là cách duy nhất để xác định thuật toán lấy XML làm đầu vào và đầu ra Something. Nếu thuật toán của bạn đủ phức tạp, thực tế đầu vào là XML sẽ không liên quan đến lựa chọn công cụ của bạn - tức là bạn tự cuộn mình trong C++/Python/sao cũng được.

Cụ thể với ví dụ của bạn, tôi sẽ tưởng tượng ý tưởng tốt nhất sẽ là tạo XML-> chuyển đổi XML của riêng bạn theo logic kinh doanh 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 có gì thông minh. Đó có thể là một nền tảng tốt đẹp 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 ở đầu ra giúp tạo các định dạng đầu ra thay thế dễ dàng hơn - có thể in được, cho điện thoại di động, v.v.

7
Tom Leys

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 polyglot (X) (trình bày cùng một dữ liệu theo các cách khác nhau), nguồn cấp RSS, một Atom feed, a RDF tệp mô tả và đoạn của bản đồ trang web.

Nó không phải là thuốc chữa bách bệnh. Có những thứ nó hoạt động tốt, và có những thứ nó không hoạt động tốt, và giống như tất cả các khía cạnh khác của lập trình, đó là tất cả về việc sử dụng đúng công cụ cho đúng công việc. Đó là một công cụ đá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 để làm như vậy.

6
Alohci

Tôi chắc chắn sẽ giới thiệu để dính nó ra. Đặc biệt nếu bạn đang sử dụng visual studio đã tích hợp sẵn các công cụ chỉnh sửa, xem và gỡ lỗi cho XSLT.

Vâng, đó là một nỗi đau trong khi bạn đang học, nhưng hầu hết nỗi đau là để làm quen. Cơn đau giảm dần khi bạn học ngôn ngữ.

W3schools có hai bài viết có giá trị đặc biệt: http://www.w3schools.com/xpath/xpath_fifts.asphttp://www.w3schools.com/xsl/xsl_fifts. asp

4
Nat

XSLT rất khó để làm việc với nó, nhưng một khi bạn chinh phục nó, bạn sẽ có một sự hiểu biết 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 chức năng và điều này sẽ đưa ra các kỹ thuật và cách thức mới để giải quyết vấn đề. Trong một số trường hợp, chuyển đổi liên tiếp mạnh hơn các giải pháp thủ tục.

3
David Robbins

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

Trường hợp thất bại là thực thi.

Vấn đề 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 các khía cạnh chức năng chỉ làm cho toàn bộ điều này trở nên 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ĩ đó là một phần quan điểm của thiết kế - 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!

3
Schneider

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 điều đó 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 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 chứ không phải mã C++ sử dụng các thư viện Xerces.

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

Lợi ích lớn 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 thuận. Và thông số kỹ thuật là 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 nhở tôi về các lập trình viên C thời xưa thích nghi với việc sử dụng OO khi viết C++.

Tôi đã sử dụng các công cụ này khi chúng cho phép tôi viết một cơ sở mã C++ nhỏ tách biệt với tất cả nhưng cơ bản nhất là sửa đổi cấu trúc dữ liệu và những thay đổi sau này là 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 lâu dài cho một dự án phần mềm.

3
Sam

Tôi sử dụng XSLT rộng rãi, cho giao diện người dùng tùy chỉnh kiểu MVC. Mô hình được "tuần tự hóa" thành xml (không qua xml serializaiton), sau đó được chuyển đổi sang html qua xslt. Ưu điểm của ASP.NET nằm ở sự tích hợp tự nhiên với XPath và các yêu cầu về hình thức tốt chặt chẽ hơn (lý do dễ hiểu 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ữ chứa một số hạn chế (ví dụ: khả năng biến đổi đầu ra của một biến đổi khác) có nghĩa là đôi khi nó gây khó chịu khi làm việc.

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

3
Eamon Nerbonne

Tôi đã 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 chúng tôi trả về từ "tầng trung lưu" là bằng XML và các trang sẽ được hiển thị bằng HTML cũng có thể là XHTML, cộng với họ đã nghe nói rằng XSL là một tiêu chuẩn để chuyển đổi giữa XML định dạng. Vì vậy, các "kiến trúc sư" (theo ý tôi là những người nghĩ những 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 triển khai 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 để viết. Và vì vậy tất cả các trang của chúng tôi rất khó để viết và duy trì. Chúng tôi đã làm tốt hơn nhiều khi sử dụng JSP (đây là trong Java) hoặc một số cách tiếp cận tương tự đã sử dụng một loại đánh dấu (dấu ngoặc góc) 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 ... thật khó để giữ cả 3 tài liệu XML khác nhau trong tâm trí của một người.

Tình huống của bạn hơi khác một chút: thay vì tác giả mỗi 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 để hiển thị). Nhưng có vẻ như bạn có thể gặp phải loại khó khăn tương tự như tôi đã làm. Tôi muốn nói rằng việc cố gắng diễn giải một DSL (ngôn ngữ cụ thể theo miền) đơn giả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 tất cả, nó IS Hoàn thành!)

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 cho 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

3
mcherm

Nó đi xuống những gì bạn cần nó cho. Sức mạnh chính của nó là khả năng duy trì dễ dàng của biến đổi và viết trình phân tích cú pháp của riêng bạn thường xóa sạch đ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 "ưa thích". Miễn là trình xây dựng dựa trên mã của bạn có thể thay thế mà không 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í. Vâng, phải mất một số làm quen. Nhưng một khi bạn hiểu rõ về nó (không nên mất IMO lâu), nó thực sự thuận buồm xuôi gió. Các biến đổi được biên dịch chạy khá nhanh theo kinh nghiệm của tôi và bạn chắc chắn có thể gỡ lỗi chúng.

2
SpongeJim

đặc tả XSLT định nghĩa XSLT là "ngôn ngữ để chuyển đổi các 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ì ngoại trừ việc xử lý dữ liệu cơ bản nhất trong XSLT, có thể có các giải pháp tốt hơn.

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

2
Eric Schoonover

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

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 loại công nghệ liên kết/sắp xếp XML (như JiBX trong Java) sẽ chuyển đổi XML của bạn thành đối tượng.

2
Tom Martin

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. Các nhà văn 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. Đây chỉ là vấn đề thay đổi XSLT.

Điều này làm việc tốt cho chúng tôi. Trong trường hợp của chúng tôi, nó là một 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 vấn đề của mình (HTML). Tôi luôn coi đó là ý tưởng tốt.

Cuối cùng, nếu hệ thống hiện tại của bạn hoạt động, hãy để nó một mình. Tôi sẽ không bao giờ đề nghị bỏ rác mã hiện tại của bạn. 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ó.

2
Mashed Potato

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à có ý nghĩa.

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) để xử lý lớp dữ liệu/xử lý, nhưng xuất ra XML chứ không phải HTML. API dữ liệu, hoặc được XSLTs hiển thị dưới dạng HTML. Vì C # đã 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 nó rất trơn tru và logic trình bày được giữ theo cách khai báo. Dễ dàng theo dõi và thay đổi hơn so với gửi các thẻ từ C #.

Tuy nhiên, khi bạn yêu cầu logic xử lý nhiều hơn ở cấp XSLT, nó sẽ bị rối và dài dòng - ngay cả khi bạn "có được" kiểu chức năng.

Tất nhiên, những ngày này có lẽ tôi đã 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 lực kéo trong các khu vực mà XML thường được XSLT chuyển đổi. Nhưng hiện tại XSLT vẫn là một công nghệ quan trọng và hữu ích.

2
philsquared

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.

Vâng, 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à thậm chí bạn 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ố tiền xử lý với XML (được tạo).

Bất kỳ ai có kiến ​​thức về XSLT đều có thể thay đổi độ trễ của sản phẩm hoàn chỉnh vì nó không được biên dịch.

1
Toon Krijthe

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

1
Sam Harwell

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

  1. Tôi đã sử dụng XSLT một vài năm trước đây.
  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 đánh giá của bạn rằng nó hầu như hữu ích cho các phép biến đổi 'đơn giản'. Nhưng tôi nghĩ miễn là bạn hiểu rõ về XSLT, có một trường hợp được tạo ra để sử dụng nó cho các nhiệm vụ lớn hơn như xuất bản một trang web khi XML chuyển 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 cơ bản mà nó dựa trên. Nhưng với sự quan tâm gần đây về lập trình chức năng, chúng ta có thể thấy XSLT đang trở lại ...

1
Dawie Strauss

Tôi đã dành rất nhiều thời gian trong XSLT và thấy rằng mặc dù nó là một công cụ hữu ích trong một số tình huống, nhưng nó chắc chắn không phải là một 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ố 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 một số ngôn ngữ đánh dấu khác có sẵn. Tôi tin rằng Jeff đã làm một bài viết về chính 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 những gì anh ấy viết. Bạn có thể 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 "ra khỏi hộp", hoặc ít nhất là rất gần thay vì viết nội dung của riêng bạn từ đầu.

1
Jason Jackson

Một nơi mà xslt thực sự tỏa sáng là trong việc tạo báo cáo. Tôi đã thấy rằng quy trình 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 báo cáo trực quan Nice trong khi vẫn giữ dữ liệu thô xung quanh như một cơ chế xác thực nếu cần.

1
Jack Ryan

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

Có lẽ 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ó những thư viện cho điều đó và nếu XSLT không hoạt động cho bạn, có lẽ XML cũng không hoạt động với chúng.

1
brianary

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

1
Goran

Tôi nghĩ rằng bạn đã làm đúng. Theo kinh nghiệm của tôi, các nhà phát triển XSLT là một trong những người rất khó thuê, bởi vì đó là ngôn ngữ không bao giờ bị bắt gặp với các nhà phát triển Web cũng như với các lập trình viên thông thường.

Vì vậy, cuối cùng bạn phải trả phí bảo hiểm "lập trình viên tiên tiến, người biết một ngôn ngữ ngoài dòng chính", nhưng đối với một ngôn ngữ có lẽ không phải là ngôn ngữ yêu thích của lập trình viên đó.

0
Larry OBrien

Tôi đã có trải nghiệm khá tốt với XSLT, nhưng tôi đã không chuyển đổi thành HTML. Có thể là kết hợp XSLT-HTML là một điều rất khó khăn để hoàn thành công việc.

0
Rolf

Theo tôi thì có.

Để có một ví dụ tuyệt vời về việc sử dụng XSLT thực sự tuyệt vời, hãy xem thế giới kho vũ khí của Blizzard.

http://www.wowarmory.com

0
Vinh

XSLT 1.0 là một trong những mã di động nhất, ít nhất là trên máy tính để bàn và máy chủ. Bởi vì nó có một (và thường là nhiều) thời gian chạy trên hầu hết các hệ thống đó:

  • Microsoft Windows có MSXML được cài đặt trong hệ thống cơ sở kể từ ít nhất là Windows 2000. Nó có thể được sử dụng cả từ MSIE, từ dòng lệnh (sử dụng WSH) hoặc từ các ứng dụng Office
  • Java Môi trường thời gian chạy (JRE) có thời gian chạy XSLT và JRE được cài đặt trên hầu hết các máy tính để bàn
  • Hầu như tất cả các trình duyệt web lớn có một. Opera là ngoại lệ.
  • Có các triển khai miễn phí được cài đặt theo mặc định trên các hệ điều hành chính GNU (libxslt, xsltproc)
  • Tôi đã không kiểm tra MacOS X, nhưng ít nhất nó đã được triển khai trong Safari

Điều này làm cho nó phù hợp để xây dựng một số ứng dụng yêu cầu cả tính di động và nhẹ/không cần cài đặt.

Ngoài ra, XSLT chỉ yêu cầu thời gian chạy (không cần trình biên dịch) và bạn có thể tạo mã chỉ với bất kỳ trình soạn thảo văn bản nào. Vì vậy, bạn có thể tạo chương trình dễ dàng (tốt, một khi bạn thành thạo ngôn ngữ) từ bất kỳ máy tính để bàn nào.

0
dolmen

Tôi đã sử dụng XSLT rộng rãi ... trong một vài giờ. Thật tuyệt vời cho những thứ như thay đổi tên thành phần hoặc lọc tài liệu đầu vào (tước bỏ những thứ bạn không cần).

Bất cứ điều gì khác trở nên phức tạp rất nhanh. Sự phức tạp vốn có này cộng với việc thiếu hầu hết mọi thứ bạn sử dụng từ bất kỳ ngôn ngữ lập trình nào khác (như biến) và những cách dễ dàng để làm cho các biểu thức XPath không thể đọc được, thực sự gây tổn thương.

Cuối cùng, XSLT bị mắc chứng phân liệt: Các lập trình viên không thích nó vì những hạn chế và mọi người khác không thể sử dụng nó (giả sử, nhà thiết kế web hoặc bất kỳ loại không lập trình viên nào khác).

Nếu XSLT đã được quảng bá dưới dạng một loại SQL cho XML, mọi thứ sẽ khác một chút. Đầu tiên, mọi người thậm chí sẽ không buồn nhìn vào nó. Và những người đã không ngạc nhiên trước nỗi đau.

0
Aaron Digulla

Tôi nghĩ rằng khái niệm này là âm thanh, có lẽ việc thực thi không phải là 'sạch' như nó có thể.

Tuy nhiên tôi nghĩ rằng nó nên được coi là một công cụ, có thể không khôn ngoan khi sử dụng nó trong mọi trường hợp, tuy nhiên người ta không bao giờ nên bỏ qua một công cụ khi giải quyết các giải pháp.

Tôi đã thấy XSLT rất tốt và cũng sử dụng XSLT rất tệ và tôi kết luận một số có thể là do kỹ năng của nhà phát triển. Tôi nghĩ rằng một trong đó đòi hỏi nhà phát triển phải suy nghĩ trong nhiều lĩnh vực cùng một lúc.

Nó có phải là tương lai không? có thể không, có thể có giải pháp tốt hơn ..

Tôi không biết công nghệ mới nào sẽ xuất hiện, nhưng ít nhất là tốt nhất để học nó, tăng bộ công cụ của riêng mình có phải là một điều tồi tệ không?

0
Darknight

Tôi sử dụng XSLT để sửa lỗi trong các tệp xml rất phức tạp. Vì vậy, thay vì xử lý các lỗi trong xml, tôi sử dụng xslt để sửa chúng.

Điều đó thật tuyệt. Bởi vì ngôn ngữ rất mạnh mẽ và phù hợp với trường hợp sử dụng xml. Để làm những điều tương tự trong một ngôn ngữ lập trình thông dụng, tôi sẽ mất nhiều thời gian để điều chỉnh mã của mình mỗi khi một hương vị mới xuất hiện.

Nó cũng hữu ích để di chuyển các giải pháp phòng thu trực quan mà không để Microsoft quyết định điều gì sẽ thay đổi. Vì vậy, chuyển đổi một giải pháp. Kiểm tra những gì đã thay đổi. Hoàn nguyên những thứ bạn không muốn thay đổi và chạy tập lệnh xslt đang thực hiện công việc trên tất cả các tệp.

Vì vậy, tôi không bao giờ sử dụng nó để trình bày web hoặc một cái gì đó như thế này nhưng nó giúp tôi trong các vấn đề dựa trên xml của tôi. Và để giải quyết những vấn đề này, nó thực sự rất mạnh mẽ và thực sự đáng để xem xét về nó.

0
Totonga

XSLT không phải là biến đổi cuối cùng của tất cả các 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 đó là giải pháp tốt nhất cho vấn đề của bạn hoặc nếu có các phương pháp hiệu quả và duy trì khác. Bạn nói rằng các tác giả có thể nhập nội dung của họ trong một định dạng đơn giản - định dạng nào? Hộp văn bản? Loại html nào bạn đã chuyển đổi nó thành? Để đánh giá liệu XSLT có phải là công cụ phù hợp cho công việc hay không, sẽ giúp biết chi tiết hơn về các tính năng của chuyển đổi này.

0
Shmoggle

Tôi cũng đã thực hiện các bước đột phá vào thế giới của XSLT và tôi thấy nó hơi khó xử ở những nơi. Tôi nghĩ vấn đề chính của tôi là khó khăn trong việc chuyển đổi XML "dữ liệu thuần túy" thành một trang HTML hoàn chỉnh. Nhìn chung, có lẽ sử dụng XSLT để tạo một đoạn trang có thể được tạo cùng với các đoạn khác bằng cách sử dụng Server Side Scripting (ví dụ: SSI) sẽ giải quyết được nhiều vấn đề của tôi.

Một trong những sai lầm có thể xảy ra là thử và xây dựng bố cục trang chung để bao quanh dữ liệu của tôi bằng cách nhập XHTML hoặc dữ liệu XML khác bằng cách sử dụng hàm document ().

Một lỗi khác là cố gắng làm những việc có lập trình như tạo một mẫu chung để tạo các bảng trên dữ liệu XML với logic đã làm những việc như sử dụng các màu hàng nền khác nhau cho các hàng với các giá trị nhất định và cho phép bạn chỉ định một số cột được lọc.

Không đề cập đến việc cố gắng xây dựng một danh sách chuỗi các giá trị từ dữ liệu XML mà dường như chỉ có thể giải quyết được bằng cách sử dụng các cuộc gọi mẫu đệ quy.

Tôi đã đạt được gì? Chà, nguồn trang là dữ liệu XML ngay tại đó và có sẵn cho người xem. Dữ liệu và trình bày được phân tách gọn gàng.

Tôi sẽ làm điều đó một lần nữa? Có lẽ là không, trừ khi tôi thực sự muốn tách dữ liệu/trình bày trên trang tĩnh. Mặt khác, tôi có thể viết một Rails hoặc Java ứng dụng EE có thể tạo chế độ xem XML hoặc chế độ xem HTML bằng cách sử dụng templating - tất cả các lợi ích, nhưng với một ngôn ngữ lập trình tự nhiên hơn (đối với tôi) trong tầm tay tôi.

0
Mike Tunnicliffe

Tôi chỉ thích sử dụng XSLT để thay đổi cấu trúc cây của các tài liệu XML. Tôi thấy thật khó khăn khi làm bất cứ điều gì liên quan đến xử lý văn bản và chuyển nó thành 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ĩ nó không phù hợp với ngôn ngữ và không có nhiều triển khai XSLT 2.0.

0
Ben

Về năng suất tuyệt đối, bạn sẽ tốt hơn khi sử dụng một trong các thư viện kiểu jQuery - pyQuery, phpQuery, v.v. Hầu hết các thư viện XML hút và XSLT về cơ bản chỉ là một thư viện XML khác được đóng gói như một ngôn ngữ chính thức nhưng không có một bộ công cụ hợp lý . jQuery làm cho nó dễ dàng vượt qua và thao tác dữ liệu kiểu XML theo ngôn ngữ bạn chọn.

0
Jimmy

Nói về khả năng tương tác, XML là một tiêu chuẩn để lưu trữ thông tin. Toàn bộ nhiều công cụ tạo ra đầu ra bằng XML và cách trình bày nó tốt hơn (hoặc dễ dàng hơn) hơn là nhúng trình duyệt vào ứng dụng của bạn và định dạng XML và đưa nó vào trình duyệt.

0
Midhat

Tôi cần làm việc với XSLT ở đây vì một số người cho rằng nên giải quyết một vấn đề nhất định: Chúng tôi cần trích xuất một số dữ liệu từ nhiều tệp XML và kết hợp nó với các định dạng đầu ra khác nhau để xử lý thêm.

Fisrt Tôi nghĩ XSLT là một ý tưởng rất hay, bởi vì đó là một tiêu chuẩn mà bạn có thể dựa vào. Điều này đúng cho các nhiệm vụ hình thành đơn giản mà bạn không cần nhiều logic lập trình hoặc thuật toán trong mã của mình.

Nhưng: Đó là một bước học tập khá, vì nó là không thủ tục. Nếu bạn đã quen với lập trình thủ tục (C, Java, Perl, PHP, v.v.), bạn sẽ bỏ lỡ rất nhiều cấu trúc phổ biến hoặc bạn sẽ tự hỏi về những điều chỉ may mắn lập thể và đôi khi không thực sự có thể đọc được bằng mắt. Ví dụ: viết mã "có thể bán lại": Nếu bạn cần làm đi làm lại nhiều lần ở những nơi khác nhau, trong lập trình thủ tục, bạn sẽ xác định một hàm để làm như vậy. Bạn cũng có thể đạt được những điều như vậy trong XSLT, nhưng để có nhiều mã hơn để viết và không thể đọc/hiểu được như một chức năng bình thường.

Vấn đề chính tôi gặp phải là nhiều người đến từ nền tảng thủ tục đã làm việc trên XSLT-Files và hầu như mọi người chỉ "mô phỏng" những gì anh ta cần.

Vì vậy, như một kết luận: Tôi không thấy XSLT là giải pháp "tối thượng" nữa. Trong thực tế, thật khó để đọc hoặc viết một số cấu trúc trong XSLT. Trong hầu hết các trường hợp, bạn sẽ phải suy nghĩ về ứng dụng: Để chuyển đổi đơn giản, tôi có thể sẽ sử dụng lại XSLT. Nhưng đối với phần mềm phức tạp hơn, tôi sẽ không sử dụng lại.

0
Murphy