İstemci Tarafı XSLT'yi kullanan büyük siteler var mı?

Question

Son zamanlarda, sunucu tarafında ham XML oluşturma ana akım olmayan mimarisi üzerinde duruluyor ve sonra istemcideki bir XSLT stil sayfasını kullanarak XML'i tüm kullanıcı arayüzüne dönüştürüyordum. Tabii ki, istemci istemci tarafı XSLT yeteneğine sahip değilse, bir geri dönüş mekanizması var olmalıdır, bu durumda sadece sunucu tarafında onlar için dönüştürürüz.

Zaten XSLT'yi yakından tanıyorum ve bu yaklaşım, verileri XML'ye zorlayarak ve sunum için XSLT'yi kullanarak, sunumun ve içeriğin temiz bir şekilde ayrılması gibi görünüyor.

Ayrıca, bunun, uygulama için fazladan bir karmaşıklık katmanı eklediğinin farkındayım, ki bu da başarısız olabilecek başka bir hareketli parça.

Soruma şudur: Bu yaklaşımı kullanan büyük bir ad veya büyük trafik siteleri var mı, eğer öyleyse: bundan ne tür sınırlamalar/dersler aldınız?

sayesinde internet, Zach

Answer 1

, Blizzard istemci tarafı xsl birçok siteyi vardır. İstemci tarafı xsl'den kaçınmanızı tavsiye ederim. Bu gerçekten harika bir fikir, ancak etrafta çalışmanız gereken birçok sıra dışı böcek var. Firefox'ta

, DOM yok edecek document.write kullanan herhangi bir javascript. Ayrıca, firefox için noscript eklentisi istemci tarafı xsl'yi durdurur. Her iki durumda da, kullanıcı hiçbir şey görmeyecektir. Bu tür bir hatayı tespit etmenin bir yolu yok gibi gözüküyor, dolayısıyla bir geri dönüş işe yaramayacak. Eğer farklı kökenli bir şeye bir 30x yönlendirme yapar şey varsa IE'de

, (https için http gidiş veya alt etki alanları arasında geçiş), sen same origin policy ihlal ettiği için bir hata alırsınız. Aynı başlangıç ​​politikasını gerçekten ihlal etmediniz, ancak IE sizin yaptığınız gibi davranıyor. Örneğin, http://foo.example.com/login gidip bir 302 https://bar.example.com/login.xml yönlendiriyor eğer bar.example.com geldi sanki IE xsl davranacak ve onu foo.example.com geldi sanki xml ele alacağız. Böylece, yeniden yönlendirmeleriniz için meta yenileme gibi bir şeye dönmeniz gerekecek.

Bunlar

kafamın üst kapalı ile geldi şeylerdir. Bu düzgün bir fikir, ancak bu konuların farkında olun.

Answer 2

Ben nasıl uygulandığı ayrıntılı olarak söyleyemediğim, ama World of Warcraft oldukça büyük ve yüksek trafik olduğunu ve tarif olarak kendi web sitesi uygulanmaktadır.

Answer 3

İstemci tarafı XSLT dönüşümü kullanan büyük bir genel Web sitesi bilmiyorum (Joel, World of Warcraft hariç). Bu yüzden sorunuzu doğrudan cevaplayamıyorum. Bununla birlikte, zaman zaman ben de aynı soruyu kendim düşünürdüm ve internette bu tür sitelerin sayısının sıfıra yakın olması gerektiğine dair bir hipotezim var. :-)

Bu hipotezin arkasındaki teorimin kısa versiyonu şudur: Bazı oldukça egzotik durumlar haricinde, müşteri tarafındaki XSLT seçeneğinin sağlanması basitçe sorun olmayacaktır. :-)

Answer 4

2001'de çalıştığım şirket, tam olarak tanımladığınız mimariyi uygulayan bir sunucu ürünü yayınladı. İşlemleri müşterilere bırakarak çok iyi bir başarı yakaladık. Ayrıca, HTTP kullanıcı aracısını kullanarak istemci tespitini yaparak, Japon cep telefonları gibi çok özel müşterilere hitap etmek için sunucu tarafındaki XSL işlemlerini kullanabildik. Bence bu tekniği kullanan siteler/hizmetler/ürünler bunu müşterilere oldukça şeffaf bir şekilde yapıyor. Bununla birlikte, son zamanlarda trendin, sunucu istemcisini yapmak olduğunu düşünüyorum. Bu nedenle, çeşitli istemciler için XSL'nin belirli uygulamalarına güvenmek veya test etmek zorunda kalmazsınız ve bazı XSL uzantıları için destek alamazsınız. tarayıcıların büyük çoğunluğunu desteklerken kullanmak.

Bazı büyük isim sitelerini adlandırma sorunuzu doğrudan yanıtlamadığımı biliyorum, ancak umarım problem için değerli bir şey teklif ediyorum. Yani, temelde, şablon işleme yaparken performans tasarrufu, QA'ya, uzantıları olmayan üç veya dört tarayıcı için destek ve geliştirmeye göre daha değerli olmadıkça, sunucu tarafı işlemeye devam etmemenizdir.

Answer 5

Ben Elijah'ın cevabına katılıyorum. Ben istemci tarafı XSLT kullanarak zor bir iş olduğunu düşünüyorum. Bunun için çok fazla QA yapmanız gerekiyor. Ancak sunucu tarafı ile, o QA yok. İstemci tarafını kullanırken her çeşit müşteriye ve imkanlara dikkat etmelisiniz. İstemci tarafı XSLT kullanırken kodunuzun kırılması olasılığı olabilir.

Answer 6

Bunu söylediğimde önyargılı olabilir, ancak bunu yapan web tabanlı bir uygulama üzerinde çalışıyorum, bundan nefret ediyorum. Uygulanabilir olmasının tek nedeni, müşterilerin sadece IE6 + 'dır. O zaman bile, onunla ilgili sorunlar var. XSLT'yi çok zor buluyorum ve XSLT'yi ayıklamak ve düzenlemek için iyi bir araç almak için bunu yapacaksanız öneririm.Neden JSON ve jquery kullanmıyorsunuz? Daha standart ve daha az istemci tarafı değişkenliği olmalı.

Diğer kişilerin de söylediğim gibi

Answer 7

Şu anda olsa hepsi İsveçli içinde, istemci tarafı XSLT ile birkaç küçük sayfaları çalıştırıyorum (lillemanfestivalen.se, resihop.nu ve beta projeleri). En büyük endişem, google'ın sayfa içeriğimi, yalnızca dönüştürmeden XML'yi endekslememesiydi. Ancak, bir hafta önce resihop.nu başlattığımdan beri, dönüşümü ile google 'da ortaya çıkıyor! : D

Şimdi benim diğer endişe facebook ve nasıl hallederim anlamıyorum diğer sosyal siteler vardır. Yine de, yukarı tarafların aşağı taraflardan daha büyük olduğunu düşünüyorum. Aldığım müthiş hız ve ayrılık awsome. Ve resihop.nu ile, ayrı bir API geliştirmiyorum bile, sadece geliştiricilerin sitenin kendisine yöneldim. (Daha iyi bir çalışma yapmak için daha fazla çalışma gerekecektir)