Bất kỳ trang web lớn nào sử dụng Client Side XSLT?

Question

Gần đây, tôi đã cân nhắc kiến ​​trúc không chính thống về xây dựng XML thô ở phía máy chủ và sau đó sử dụng biểu định kiểu XSLT trên máy khách để biến đổi XML thành giao diện người dùng đầy đủ. Tất nhiên, một cơ chế dự phòng sẽ phải tồn tại nếu máy khách không có khả năng của XSLT phía máy khách, trong trường hợp đó chúng ta sẽ chỉ chuyển đổi nó cho chúng ở phía máy chủ.

Tôi đã quen thuộc với XSLT và cách tiếp cận này dường như là một sự tách biệt rõ ràng giữa bản trình bày và nội dung, hoàn toàn buộc dữ liệu vào XML và sử dụng XSLT để trình bày.

Tôi cũng biết rằng điều này làm tăng thêm một lớp phức tạp cho ứng dụng, đó chỉ là một phần chuyển động khác có thể bị lỗi.

Câu hỏi của tôi là: có bất kỳ tên tuổi lớn hoặc trang web lưu lượng truy cập lớn nào sử dụng phương pháp này hay không và nếu có: bạn đã loại bỏ những hạn chế/bài học nào từ nó?

Nhờ Internet, Zach

Answer 1

Giống như những người khác đã đề cập, Blizzard có nhiều trang web là phía máy khách xsl. Tôi sẽ khuyên bạn nên tránh xsl phía khách hàng. Đó là một ý tưởng thực sự thú vị, nhưng có nhiều lỗi bất thường mà bạn cần phải làm việc xung quanh.

Trong Firefox, mọi javascript sử dụng document.write sẽ hủy DOM. Ngoài ra, plug-in noscript cho firefox dừng xsl phía máy khách. Trong cả hai trường hợp, người dùng sẽ không thấy gì cả. Dường như không có cách nào để phát hiện loại lỗi này, do đó, sự sụt giảm sẽ không hoạt động.

Trong IE, nếu bạn có bất kỳ điều gì chuyển hướng 30x sang một nguồn gốc khác (chuyển từ http sang https hoặc qua tên miền phụ), bạn sẽ gặp lỗi khi vi phạm same origin policy. Bạn đã không thực sự vi phạm chính sách gốc, nhưng IE hoạt động như bạn đã làm. Ví dụ: nếu bạn truy cập http://foo.example.com/login và chuyển hướng 302 sang https://bar.example.com/login.xml, IE sẽ xử lý xsl như thể nó đến từ bar.example.com và nó sẽ xử lý xml như thể nó đến từ foo.example.com. Vì vậy, bạn sẽ cần hoàn nguyên về thứ gì đó như làm mới meta cho các chuyển hướng của bạn.

Đây là những thứ tôi đã nghĩ ra từ đầu. Đó là một ý tưởng gọn gàng, nhưng hãy lưu ý những vấn đề này.

Answer 2

Tôi không thể nói với bạn một cách chi tiết làm thế nào nó được thực hiện, nhưng World of Warcraft là khá lớn và cao lưu lượng, và trang web của họ được thực hiện như bạn mô tả.

Answer 3

Tôi không biết bất kỳ trang web công cộng lớn nào sử dụng biến đổi XSLT phía máy khách (tốt, ngoại trừ World of Warcraft được Joel :-) đề cập. Vì vậy, tôi không thể trả lời câu hỏi của bạn trực tiếp.

Tuy nhiên, theo thời gian tôi đã suy nghĩ cùng một câu hỏi bản thân mình, và tôi có một giả thuyết rằng số lượng các trang web như vậy trên Internet phải rất gần bằng không. :-)

Phiên bản ngắn của lý thuyết của tôi đằng sau giả thuyết này là: ngoại trừ một số trường hợp khá kỳ lạ, việc cung cấp tùy chọn XSLT phía máy khách đơn giản là không đáng giá. :-)

Answer 4

Công ty tôi đã làm việc từ năm 2001 đã phát hành một sản phẩm máy chủ đã triển khai chính xác kiến ​​trúc mà bạn mô tả. Chúng tôi đã thành công rất tốt trong việc xử lý các khách hàng. Hơn nữa, việc phát hiện ứng dụng khách bằng cách sử dụng tác nhân người dùng HTTP, chúng tôi đã có thể sử dụng xử lý XSL phía máy chủ để phục vụ cho các khách hàng rất cụ thể như điện thoại di động Nhật Bản. Tôi nghĩ rằng các trang web/dịch vụ/sản phẩm sử dụng kỹ thuật này làm điều đó khá rõ ràng cho khách hàng. Tuy nhiên, tôi nghĩ xu hướng gần đây là xử lý phía máy chủ xử lý để bạn không phải dựa vào cũng như kiểm tra các triển khai cụ thể của XSL cho nhiều khách hàng và bạn nhận được hỗ trợ cho một số tiện ích mở rộng XSL mà bạn sẽ không thể để sử dụng khi hỗ trợ phần lớn các trình duyệt.

Tôi biết tôi không trả lời trực tiếp câu hỏi đặt tên cho một số trang web tên tuổi lớn, nhưng tôi hy vọng tôi đang cung cấp một cái gì đó có giá trị cho vấn đề. Do đó, về cơ bản, trừ khi hiệu suất tiết kiệm của việc xử lý mẫu của bạn có giá trị hơn việc phải hỗ trợ, hỗ trợ và phát triển cho ba hoặc bốn trình duyệt không có phần mở rộng, thì bạn nên gắn với xử lý phía máy chủ.

Answer 5

Tôi đồng ý với câu trả lời của Elijah. Tôi nghĩ rằng việc sử dụng XSLT phía máy khách là một công việc khó khăn. Bạn phải làm rất nhiều QA cho nó. Nhưng trong khi với phía máy chủ, bạn không có QA đó. Bạn phải chăm sóc tất cả các loại khách hàng và khả năng trong khi sử dụng phía khách hàng. Có thể có khả năng mã của bạn có thể bị hỏng khi sử dụng XSLT phía máy khách.

Answer 6

Tôi có thể thiên vị khi tôi nói điều này, nhưng làm việc trên một ứng dụng dựa trên web thực hiện điều này, tôi ghét nó. Lý do duy nhất nó thậm chí còn khả thi là bởi vì các khách hàng chỉ là IE6 +. Thậm chí sau đó, có vấn đề với nó. Tôi thấy XSLT rất khó và sẽ gợi ý nếu bạn định làm điều này để có được một công cụ tốt để gỡ lỗi và chỉnh sửa XSLT.Tại sao không sử dụng JSON và jquery? Phải thay đổi tiêu chuẩn và ít khách hàng hơn.

Answer 7

Tôi hiện đang chạy một vài trang nhỏ với XSLT phía máy khách, tất cả trong tiếng Thụy Điển mặc dù (lillemanfestivalen.se, resihop.nu và dự án beta). Mối quan tâm lớn nhất của tôi là google không lập chỉ mục nội dung trang của tôi, chỉ là XML mà không cần chuyển đổi. Tuy nhiên, kể từ khi tôi khởi chạy resihop.nu một tuần trước, nó xuất hiện trên google với chuyển đổi! : D

Bây giờ mối quan tâm khác của tôi là facebook và các trang web xã hội khác, không hiểu cách xử lý. Tuy nhiên, tôi vẫn nghĩ rằng các mặt lên là lớn hơn các bên xuống. Tốc độ và sự tách biệt tuyệt vời mà tôi nhận được là rất đáng lo ngại. Và với resihop.nu, tôi thậm chí không phát triển một API riêng biệt, tôi chỉ trỏ các nhà phát triển đến chính trang web đó. (Sẽ cần nhiều công việc hơn để làm cho nó tốt)