XSLT buna değer mi? [kapalı]

Bir süre önce html-esque XML şeması tasarladığım bir projeye başladım, böylelikle yazarların içeriklerini (eğitici ders materyalleri) daha sonra XSLT aracılığıyla HTML'ye dönüştürülecek basitleştirilmiş bir formatta yazabildiler. Onunla bir süre oynadım (mücadele ettim) ve çok basit bir seviyeye getirdim, ancak daha sonra karşılaştığım sınırlamalar (ki bu belki de bilgimin sınırlamaları olabilir) ve hendek yapmayı öneren bir blog okuduğumda çok rahatsız oldum XSLT ve kendi seçtiğiniz dilde kendi XML'den ayrıştırıcınızı yazın, hevesle buna atladım ve mükemmel bir şekilde sonuçlandı.

Hala bu gün üzerinde çalışıyorum ( aslında şu anda SO üzerinde oynamak yerine üzerinde çalışmam gerekiyor ) ve giderek daha fazla şey görüyorum ki XSLT'den kurtulma kararım iyiydi.

XSLT'nin yerini aldığını, kabul gören bir standart olduğunu ve herkes kendi tercümanlarını yazıyorsa% 90'ının TheDailyWTF'ye . Ancak, çoğu programcının aşina olduğu yordamsal stil yerine işlevsel bir stil dili olduğu düşünüldüğünde, benimki gibi bir projeye başlayan biri için benim yaptığım yoldan gitmelerini tavsiye eder misiniz, yoksa XSLT ile devam ettirin. ?

XSLT'nin Avantajları:

• XML için etki alanına özgüdür, bu nedenle örneğin çıktıda değişmez XML alıntı yapmaya gerek yoktur.
• Normal ifadelerin dizeleri sorgulamanın güzel bir yolu olabileceği gibi, DOM'ları sorgulamanın güzel bir yolu olabilen XPath / XQuery'yi destekler.
• Fonksiyonel dil.

XSLT'nin dezavantajları:

• Müstehcen bir şekilde ayrıntılı olabilir - birebir XML'den alıntı yapmanız gerekmez, bu da etkili bir şekilde kodu alıntı yapmanız gerektiği anlamına gelir. Ve hoş bir şekilde değil. Ama yine de, tipik SGK'nizden çok daha kötü değil.
• Çoğu programcının doğal olarak kabul ettiği belirli şeyleri yapmaz. Örneğin dize manipülasyonu bir angarya olabilir. Bu, acemiler kod tasarladığında "talihsiz anlara" yol açabilir, ardından orada olacağını ve kendilerine yazmaya zaman vermediklerini sandıkları işlevleri nasıl uygulayacaklarına dair ipuçları için çılgınca web'de arama yaparlar.
• Fonksiyonel dil.

Bu arada, prosedürel davranış elde etmenin bir yolu, birden çok dönüşümü birbirine zincirlemektir. Her adımdan sonra, o adımdaki değişiklikleri yansıtan, üzerinde çalışabileceğiniz yepyeni bir DOM'a sahip olursunuz. Bazı XSL işlemcilerin bunu tek bir dönüşümde etkili bir şekilde yapacak uzantıları vardır, ancak ayrıntıları unutuyorum.

Dolayısıyla, kodunuz çoğunlukla çıktıysa ve çok fazla mantık yoksa, XSLT onu ifade etmenin çok düzgün bir yolu olabilir. Çok fazla mantık varsa, ancak çoğunlukla XSLT'de yerleşik olan formlar varsa (falan gibi görünen tüm öğeleri seçin ve her bir çıktı için vesaire), bu muhtemelen oldukça dostça bir ortam olacaktır. Her zaman XML'e dayalı düşünmeyi seviyorsanız, XSLT 2'ye bir şans verin.

Aksi takdirde, en sevdiğiniz programlama dilinin XPath'i destekleyen ve kullanışlı bir şekilde belgeler oluşturmanıza izin veren iyi bir DOM uygulaması varsa, XSLT kullanmanın birkaç yararı olduğunu söyleyebilirim. Libxml2 ve gdome2'ye bağlanmalar iyi bir şekilde yapılmalı ve iyi bildiğiniz genel amaçlı dillere bağlı kalmaktan utanılacak bir şey yok.

Evde yetiştirilen XML ayrıştırıcılar genellikle eksiktir (bu durumda bir gün sıkışmış olursunuz) veya raftan alabileceğiniz bir şeyden çok daha küçük değildir (bu durumda muhtemelen zamanınızı boşa harcıyorsunuzdur) ve kötü amaçlı girdilerle ilgili ciddi güvenlik sorunları ortaya çıkarmak için çok sayıda fırsat. Yaparak ne kazandığınızı tam olarak bilmiyorsanız bir tane yazmayın. XML'in sunduğu her şeye ihtiyacınız yoksa, girdi biçiminiz olarak XML'den daha basit bir şey için ayrıştırıcı yazamazsınız demek değildir.

Çok fazla olumsuzluk!

XSLT'yi birkaç yıldır kullanıyorum ve gerçekten seviyorum. Farkına varmanız gereken en önemli şey, bunun bir programlama dili olmadığı, bir şablon dili olmasıdır. (ve bu bakımdan onu asp.net / spit'ten tarif edilemez bir şekilde üstün buluyorum).

XML bugün web geliştirmenin fiili veri formatıdır; yapılandırma dosyaları, ham veriler veya bellek yeniden düzenlemesi. XSLT ve XPath size muazzam bir bu verileri istediğiniz herhangi bir çıktı formatına dönüştürmek güçlü ve çok verimli bir yol sunar ve size sunumu verilerden ayırmanın MVC yönünü anında verir.

Bir de fayda yetenekleri var: ad alanlarını temizlemek, farklı şema tanımlarını tanımak, belgeleri birleştirmek.

Gerekir Kendi şirket içi yöntemler geliştirerek daha XSLT ile başa çıkmak için daha iyi. En azından XSLT bir standarttır ve karşılığında kiralayabileceğiniz bir şeydir ve eğer ekibiniz için gerçekten bir sorunsa, doğası gereği ekibinizin çoğunun sadece XML ile çalışmasını sağlar.

Gerçek dünya kullanım örneği: Sistem genelinde bellek içi XML belgelerini işleyen ve son kullanıcının istediği şekilde JSON, HTML veya XML'e dönüştüren bir uygulama yazdım. Excel verileri olarak sağlamak için oldukça rastgele bir istekte bulundum. Eski bir meslektaş, programlı olarak benzer bir şey yapmıştı, ancak birkaç sınıf dosyadan oluşan bir modül ve sunucuda MS Office'in kurulu olması gerekiyordu! Excel'in bir XSD'ye sahip olduğu ortaya çıktı: 3 saat içinde minimum temel kod etkisi ile yeni işlev.

Şahsen bunun kariyerimde karşılaştığım en temiz şeylerden biri olduğunu düşünüyorum ve tüm görünen sorunlarının (hata ayıklama, dizi manipülasyonu, programlama yapıları) aracın hatalı bir şekilde anlaşılmasına bağlı olduğuna inanıyorum.

Açıkçası, "buna değer" olduğuna inanıyorum.

Burada bir önyargıyı kabul etmeliyim çünkü XSLT'yi yaşamak için öğretiyorum. Ancak, öğrencilerimin çalıştığını gördüğüm alanları örtmeye değer olabilir. Genel olarak üç gruba ayrılırlar: yayıncılık, bankacılık ve web.

Şimdiye kadarki yanıtların çoğu "web siteleri oluşturmak için iyi değil" veya "X dili gibi değil" şeklinde özetlenebilir. Birçok teknoloji adamı, işlevsel / bildirimsel dillere maruz kalmadan kariyerlerinden geçer. Öğretirken, deneyimli Java / VB / C / etc halkı dille sorunları olanlardır (değişkenler cebir anlamındaki değişkenlerdir, örneğin prosedürel programlama değil). Burada cevap verenlerin çoğu bu - Java ile hiç anlaşamadım ama bu yüzden dili eleştirme zahmetine girmeyeceğim.

Çoğu durumda, web siteleri oluşturmak için uygun olmayan bir araçtır - genel amaçlı bir programlama dili daha iyi olabilir. Genellikle çok büyük XML belgeleri alıp bunları web'de sunmam gerekir; XSLT bunu önemsiz kılıyor. Bu alanda gördüğüm öğrenciler veri kümelerini işleme ve web'de sunma eğiliminde. XSLT kesinlikle bu alandaki tek uygulanabilir araç değildir. Ancak, birçoğu bunu yapmak için DOM'u kullanıyor ve XSLT kesinlikle daha az ağrılı.

Gördüğüm bankacılık öğrencileri genel olarak bir DataPower kutusu kullanıyor. Bu bir XML aracıdır ve farklı XML lehçelerini 'konuşan' hizmetler arasında oturmak için kullanılır. XSLT'de bir XML dilinden diğerine dönüşüm neredeyse önemsiz ve bununla ilgili kurslarıma katılan öğrenci sayısı artıyor.

Gördüğüm son öğrenci grubu (benim gibi) yayıncılık geçmişinden geliyor. Bu insanlar XML'de devasa belgelere sahip olma eğilimindedir (inan bana, bir endüstri olarak yayıncılık XML'e giriyor - teknik yayıncılık yıllardır oradaydı ve ticari yayıncılık şimdi oraya geliyor). Bu belgelerin işlenmesi gerekiyor (burada DocBook to ePub akla geliyor).

Yukarıdaki biri, komut dosyalarının 60 satırın altında olma eğiliminde olduğu veya kullanışsız hale geldiği yorumunu yaptı. İşiniz hantal hale gelirse, kodlayıcı bu fikri gerçekten anlamamış olabilir - XSLT diğer birçok dilden çok farklı bir zihniyettir. Eğer zihniyete sahip değilseniz, işe yaramaz.

Kesinlikle ölmekte olan bir dil değil (aldığım işin miktarı bana bunu söylüyor). Şu anda, Microsoft XSLT 2'nin (çok geç) uygulamasını bitirene kadar biraz 'sıkışmış'. Ama hala orada ve benim bakış açımdan güçlü gidiyor gibi görünüyor.

XSLT'yi dokümantasyon gibi şeyler için kapsamlı bir şekilde kullanıyoruz ve bazı karmaşık yapılandırma ayarlarını kullanıcı tarafından bakım yapılabilir hale getiriyoruz.

Dokümantasyon için, XML tabanlı bir format olan çok sayıda DocBook kullanıyoruz. Bu, dosyalar düz metin olduğundan, belgelerimizi tüm kaynak kodumuzla depolamamıza ve yönetmemize olanak tanır. XSLT ile, hem içeriği genel bir şekilde otomatik olarak oluşturmamıza hem de içeriği daha okunaklı hale getirmemize olanak tanıyan kendi belge biçimlerimizi kolayca oluşturabiliriz. Örneğin, sürüm notlarını yayınladığımızda, şuna benzeyen XML oluşturabiliriz:

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

Ve sonra XSLT'yi (yukarıdakileri DocBook'a dönüştüren) kullanarak, hata kimliklerinin otomatik olarak hata izleyicimize bağlandığı, hataların bileşene göre gruplandığı ve her şeyin formatı mükemmel şekilde tutarlı olduğu güzel sürüm notları (genellikle PDF veya HTML) elde ederiz. . Ve yukarıdaki XML, sürümler arasında nelerin değiştiğini öğrenmek için hata izleyicimizi sorgulayarak otomatik olarak oluşturulabilir.

XSLT'yi yararlı bulduğumuz diğer yer, aslında temel ürünümüzdür. Bazen üçüncü taraf sistemlerle arabirim oluştururken, verileri bir şekilde karmaşık bir HTML sayfasında işlememiz gerekir. HTML'yi ayrıştırmak çirkin, bu yüzden verileri TagSoup besliyoruz(uygun SAX XML olayları üreten, esasen HTML ile düzgün bir şekilde yazılmış XMLmiş gibi ele almamıza izin veren) gibi bir şey aracılığıyla besliyoruz ve ardından verileri dönüştürmek için ona karşı bazı XSLT çalıştırabiliriz. gerçekten çalışabileceğimiz "bilinen kararlı" bir biçime dönüştürür. Bu dönüşümü bir XSLT dosyasına ayırarak, bu, HTML formatı değiştiğinde uygulamanın kendisinin yükseltilmesine gerek olmadığı, bunun yerine son kullanıcının XSLT dosyasını kendi başına düzenleyebileceği veya e-posta gönderebileceğimiz anlamına gelir. tüm sistemin yükseltilmesine gerek kalmadan güncellenmiş bir XSLT dosyası.

Web projeleri için, günümüzde XSLT'den daha iyi görüş yönlerini ele almanın daha iyi yolları olduğunu söyleyebilirim, ancak bir teknoloji olarak kesinlikle XSLT kullanımları vardır. Dünyadaki kullanımı en kolay dil değil, ama kesinlikle ölmedi ve benim bakış açıma göre hala birçok iyi kullanım alanı var.

XSLT, bildirim temelli bir programlama dili örneğidir .

Bildirim temelli programlama dillerinin diğer örnekleri arasında düzenli ifadeler, Prolog ve SQL bulunur. Bunların tümü son derece etkileyici ve kompakttır ve genellikle tasarlandıkları görev için çok iyi tasarlanmış ve güçlüdür.

Bununla birlikte, yazılım geliştiricileri genellikle bu tür dillerden nefret ederler, çünkü bunlar daha genel OO veya prosedürel dillerden öğrenmesi ve hata ayıklaması zor olan çok farklıdır. Kompakt yapıları, genellikle yanlışlıkla çok fazla hasar vermeyi çok kolaylaştırır.

Dolayısıyla, XSLT verileri sunumla birleştirmek için etkili bir mekanizma olsa da, kullanım kolaylığı departmanında başarısız olur. Sanırım bu yüzden gerçekten tutmadı.

Standart yeni piyasaya sürüldüğünde XSLT ile ilgili tüm hype'ı hatırlıyorum. Tüm bir HTML kullanıcı arayüzünü 'basit' bir dönüşümle oluşturabilmenin tüm heyecanı.

Kabul edelim, kullanımı zor, hata ayıklaması neredeyse imkansız, çoğu zaman dayanılmaz derecede yavaş. Sonuç neredeyse her zaman ilginçtir ve idealden daha azdır.

İşleri yapmanın daha iyi yolları varken, bir XSLT kullanmaktansa kendi bacağımdan daha çabuk kemireceğim. Yine de yerleri var, basit dönüşüm görevleri için iyi.

XSLT'yi (ve ayrıca XQuery'yi) çeşitli şeyler için yoğun bir şekilde kullandım - derleme sürecinin bir parçası olarak C ++ kodu oluşturmak, belge yorumlarından dokümantasyon üretmek için ve genel olarak XML ve özellikle de XHTML ile çalışması gereken bir uygulama içinde . Özellikle kod üreteci, yaklaşık bir düzine ayrı dosyaya yayılmış 10.000 satırlık XSLT 2.0 kodundan fazlaydı (istemciler için başlıklar, uzak proxy'ler / saplamalar, COM sarmalayıcılar, .NET sarmalayıcılar, ORM gibi pek çok şey yaptı. birkaç). Bunu, dili gerçekten iyi anlamayan başka bir adamdan miras aldım ve bu nedenle eski parçalar oldukça karışıktı. Yazdığımız yeni şeyler çoğunlukla aklı başında ve okunaklı tutuldu, ancak bunu başarmakla ilgili herhangi bir özel sorun hatırlamıyorum. Kesinlikle C ++ için yapmaktan daha zor değildi.

Sürümlerden bahsetmişken, XSLT 2.0 ile uğraşmak kesinlikle aklı başında kalmanıza yardımcı olur, ancak 1.0 daha basit dönüşümler için hala uygundur. Nişinde, son derece kullanışlı bir araçtır ve belirli etki alanına özgü özelliklerden (en önemlisi, şablon eşleştirme yoluyla dinamik gönderim) elde ettiğiniz üretkenliği eşleştirmek zordur. XSLT'nin XML tabanlı sözdiziminin algılanan kelimeliğine rağmen, LINQ to XML'deki aynı şey (XML değişmez değerleriyle VB'de bile) genellikle birkaç kat daha uzundu. Bununla birlikte, çoğu zaman, bazı durumlarda ilk etapta gereksiz XML kullanımı nedeniyle haksız yere sorun yaşar.

Özetlemek gerekirse: bir kişinin alet çantasında bulunması inanılmaz derecede faydalı bir araçtır, ancak çok özel bir araçtır, bu yüzden doğru ve amacına uygun kullandığınız sürece iyidir. Gerçekten XSLT 2.0'ın düzgün, yerel bir .NET uygulaması olmasını dilerdim.

XSLT kullanıyorum (daha iyi bir alternatifin olmaması için), ancak sunum için değil, sadece dönüşüm için:

1. Maven pom.xml dosyalarımızda toplu düzenlemeler yapmak için kısa XSLT dönüşümleri yazıyorum.

2. XMI'den (UML Diyagramı) XML Şemaları oluşturmak için bir dönüşüm hattı yazdım. Bir süre işe yaradı, ama sonunda çok karmaşık hale geldi ve onu ahırın arkasından çıkarmak zorunda kaldık.

3. XML Şemalarını yeniden düzenlemek için dönüşümler kullandım.

4. Gerçek işi yapmak için XSLT'yi kullanarak XSLT'deki bazı sınırlamaları aştım. (Hiç çalışma zamanına kadar bilinmeyen ad alanlarını kullanarak bir çıktı üreten bir XSLT yazmaya çalıştınız mı?)

Buna geri dönmeye devam ediyorum, çünkü işlediği XML'i, denediğim diğer yaklaşımlardan daha iyi bir iş çıkarıyor, bunlar gereksiz yere kayıplı veya XML'i yanlış anlıyor gibi görünüyor. XSLT rahatsız edici, ancak Oksijen kullanmanın onu katlanılabilir hale getirdiğini düşünüyorum.

Bununla birlikte , XML dönüşümlerini gerçekleştirmek için Clojure (bir lisp) kullanarak araştırma yapıyorum , ancak bu yaklaşımın bana fayda sağlayıp sağlamayacağını bilmek için henüz yeterince ilerlemedim.

Kişisel olarak XSLT'yi tamamen farklı bir bağlamda kullandım. O zamanlar üzerinde çalıştığım bilgisayar oyunu, XML kullanılarak tanımlanmış tonlarca UI sayfası kullanıyordu. Yayımlandıktan kısa bir süre sonra büyük bir yeniden düzenleme sırasında bu XML belgelerinin yapısını değiştirmek istedik. Oyunun girdi formatının çok daha iyi ve şemaya duyarlı bir yapıyı takip etmesini sağladık.

XSLT eski format -> Yeni formattan bu çeviri için mükemmel bir seçim gibi görünüyordu. İki hafta içinde, yüzlerce sayfamız için eskiden yeniye çalışan bir dönüşüm gerçekleştirdim. Ayrıca, kullanıcı arayüzü sayfalarımızın düzeni hakkında birçok bilgi elde etmek için de kullanabildim. Daha sonra şema tanımlarımıza yazmak için XSLT'yi kullandım ve hangi bileşenlerin gömülü olduğu listeleri oluşturdum.

Ayrıca, C ++ geçmişinden gelen, ustalaşması çok eğlenceli ve ilginç bir dildi.

XML'i bir biçimden diğerine çevirmek için bir araç olarak harika olduğunu düşünüyorum. Ancak, XML'i girdi ve çıktı olarak alan bir algoritmayı tanımlamanın tek yolu bu değildir. şey . Algoritmanız yeterince karmaşıksa, girdinin XML olması gerçeği araç seçiminizle alakasız hale gelir - yani kendi C ++ / Python / her neyse, yuvarlayın.

Örneğinize özel olarak, en iyi fikrin, iş mantığınızı izleyen kendi XML-> XML dönüştürmenizi yaratmak olduğunu düşünürdüm. Ardından, biçimlendirmeyi bilen ve akıllıca hiçbir şey yapmayan bir XSLT tercümanı yazın. Bu güzel bir orta yol olabilir ama tamamen ne yaptığınıza bağlı. Çıktıda bir XSLT tercümanı olması, alternatif çıktı biçimleri oluşturmayı kolaylaştırır - yazdırılabilir, mobil cihazlar için vb.

Evet, çok kullanıyorum. Farklı xslt dosyalarını kullanarak, birden çok poliglot (X) HTML dosyası (aynı verileri farklı şekillerde sunan), bir RSS beslemesi, bir Atom beslemesi, bir RDF tanımlayıcı dosyası ve bir site haritasının parçası oluşturmak için aynı XML kaynağını kullanabilirim .

Her derde deva değil. İyi yaptığı ve iyi yapmadığı şeyler var ve programlamanın diğer tüm yönleri gibi, hepsi doğru iş için doğru aracı kullanmakla ilgili. Alet kutunuzda bulundurmaya değer bir araçtır, ancak yalnızca uygun olduğunda kullanılmalıdır.

Kesinlikle bunu dışarı çıkarmanızı tavsiye ederim. Özellikle, XSLT için düzenleme, görüntüleme ve hata ayıklama araçlarına sahip görsel stüdyo kullanıyorsanız.

Evet, öğrenirken bu bir acıdır, ancak acının çoğu aşinalıkla ilgilidir. Dili öğrenirken ağrı azalır.

W3schools'un özellikle değer taşıyan iki makalesi vardır: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

XSLT ile çalışmanın oldukça zor olduğunu gördüm.

Tanımladığınız sisteme biraz benzer bir sistem üzerinde çalışma deneyimim oldu. Şirketim, "orta katmandan" döndürdüğümüz verilerin XML'de olduğunu ve sayfaların HTML'de işleneceğini ve XHTML olabileceğini, ayrıca XSL'nin XML arasında dönüşüm için bir standart olduğunu duyduklarını belirtti. biçimleri. Bu yüzden "mimarlar" (derin tasarım düşünceleri düşünen ancak görünüşe göre kod yazmayan insanları kastediyorum), ön katmanımızın, verileri görüntüleme için XHTML'ye dönüştüren XSLT komut dosyaları yazarak uygulanacağına karar verdiler.

Seçim felaket oldu. Görünüşe göre XSLT yazmak için bir acı. Ve böylece tüm sayfalarımızın yazılması ve bakımı zordu. JSP'yi (bu Java'daydı) veya çıktı biçimi (HTML) için bir tür işaretleme (köşeli parantez) ve başka bir tür işaretleme (<% ... Meta veriler için%>). XSLT ile ilgili en kafa karıştırıcı şey, XML ile yazılmış olması ve XML'den XML'e çevrilmesidir ... 3 farklı XML belgesinin tamamını akılda tutmak oldukça zordur.

Durumunuz biraz farklı: Benim yaptığım gibi her sayfayı XSLT'de yazmak yerine, XSLT'de (şablonlardan ekrana dönüştürülecek kod) yalnızca BİR bit kod yazmanız gerekir. Ama benim yaptığımla aynı türden zorluklarla karşılaşmışsınız gibi görünüyor. Basit bir XML tabanlı DSL'i (etki alanına özel dil) sizin yaptığınız gibi yorumlamaya çalışmanın XSLT'nin güçlü noktalarından biri OLMADIĞINI söyleyebilirim. (İşi YAPABİLİR olmasına rağmen ... sonuçta Turing tamamlandı!)

Bununla birlikte, sahip olduğunuz şey daha basitse: tek bir XML biçiminde verileriniz varsa ve üzerinde basit değişiklikler yapmak istiyorsanız - tam sayfa tanımlı bir DSL değil, ancak bazı basit basit değişiklikler, o zaman XSLT bu amaç için mükemmel bir araçtır. Açıklayıcı (prosedürel değil) doğası aslında bu amaç için bir avantajdır.

- Michael Chermside

XSLT ile çalışmak zordur, ancak onu bir kez ele geçirdikten sonra DOM ve şemayı çok iyi anlayacaksınız. Ayrıca XPath kullanıyorsanız, işlevsel programlamayı öğrenme yolundasınız ve bu, problem çözme konusunda yeni tekniklere ve yollara maruz kalacaktır. Bazı durumlarda, ardışık dönüşüm, prosedürel çözümlerden daha güçlüdür.

Özel bir MVC stili ön uç için XSLT'yi yoğun olarak kullanıyorum. Model, xml'ye "serileştirilir" (xml serileştirme yoluyla değil) ve sonra xslt aracılığıyla html'ye dönüştürülür. ASP.NET'e göre avantajı, XPath ile doğal bütünleşmede ve daha sıkı iyi biçimlilik gereksinimlerindedir (xslt'deki belge yapısı hakkında akıl yürütmek, diğer birçok dile göre çok daha kolaydır).

Ne yazık ki, dil birkaç sınırlama içeriyor (örneğin, başka bir dönüşümün çıktısını dönüştürme yeteneği), bu da bazen birlikte çalışmanın can sıkıcı olduğu anlamına geliyor.

Yine de, kolayca elde edilebilen, güçlü bir şekilde dayatılan kaygıların ayrılması, şu anda başka bir teknolojinin sağladığını gördüğüm bir şey değil - bu nedenle, belge dönüşümleri için hala tavsiye edeceğim bir şey.

2004'te çok benzer olmayan DB sistemleri arasında bir entegrasyon projesinde XML, XSD ve XSLT kullandım. XSD ve XSLT'yi sıfırdan öğrenmem gerekiyordu ama zor olmadı. Bu araçlarla ilgili harika olan şey, verilerden bağımsız C ++ kodu yazmama, XSD ve XSLT'ye güvenerek XML belgelerini doğrulamamı / doğrulamamı ve sonra dönüştürmemi sağlamasıydı. Veri formatını değiştirin, Xerces kitaplıklarını kullanan C ++ kodunu değil, XSD ve XSLT belgelerini değiştirin.

İlgi için: ana XSD 150KB ve XSLT'nin ortalama boyutu <5KB IIRC idi.

Diğer büyük fayda, XSD'nin XSLT'nin dayandığı bir şartname belgesi olmasıdır. İkisi uyum içinde çalışır. Ve bugünlerde yazılım geliştirmede teknik özellikler nadirdir.

XSD ve XSLT'nin bildirimsel doğasını öğrenmekte çok fazla sorun yaşamamama rağmen, diğer C / C ++ programcılarının bildirimsel yola uyum sağlama konusunda büyük sorunlar yaşadıklarını gördüm. Bunu gördüklerinde, ah prosedürel mırıldandılar, şimdi anladığıma göre! Ve prosedürel XSLT yazmaya devam ettiler (pun?)! Mesele şu ki, XPath öğrenmeniz ve XML'in eksenlerini anlamanız gerekiyor. Bana eski C programcılarının C ++ yazarken OO kullanmaya alıştığını hatırlatıyor.

Bu araçları, veri yapısı değişikliklerinin en temelleri dışındaki her şeyden izole edilmiş küçük bir C ++ kod tabanı yazmamı sağladıkları için kullandım ve bunlar DB yapı değişiklikleriydi. C ++ 'ı başka herhangi bir dile tercih etsem bile, bir yazılım projesinin uzun vadeli uygulanabilirliğinden yararlanmak için yararlı olduğunu düşündüğüm şeyi kullanacağım.

XSLT'nin harika bir fikir olduğunu düşünürdüm. Bunun ne demek olduğunu çok iyi bir fikir.

Başarısız olduğu yer infazdır.

Zaman içinde keşfettiğim sorun, XML'deki programlama dillerinin sadece kötü bir fikir olduğuydu. Her şeyi aşılmaz kılıyor. Özellikle XSLT'nin öğrenmek, kodlamak ve anlamak için çok zor olduğunu düşünüyorum. İşlevsel yönlerin yanı sıra XML, her şeyi çok kafa karıştırıcı hale getiriyor. Kariyerim boyunca bunu yaklaşık 5 kez öğrenmeye çalıştım ve hiç de yapışmıyor.

Tamam, onu 'alet' edebilirsiniz - sanırım kısmen tasarımın amacı buydu - ama bu ikinci başarısızlık: piyasadaki tüm XSLT araçları oldukça basit ... saçmalık!

XSLT belirtimi tanımlar "Diğer XML belgeleri içine XML belgeleri dönüştürmek için bir dil" olarak XSLT. XSLT'deki en temel veri işleme dışında herhangi bir şey yapmaya çalışıyorsanız, muhtemelen daha iyi çözümler vardır.

Ayrıca XSLT'nin veri işleme yeteneklerinin özel uzantı işlevleri kullanılarak .NET'te genişletilebileceğini belirtmek gerekir:

• MSDN Belgeleri
• CSharpFriends: Eğitim

Şirketim için çevrimiçi bir dokümantasyon sistemi kullanıyorum. Yazarlar dokümantasyonu SGML'de (xml benzeri bir dil) oluştururlar. SGML daha sonra XSLT ile birleştirilir ve HTML'ye dönüştürülür.

Bu, herhangi bir kodlama yapmadan dokümantasyon düzeninde kolayca değişiklik yapmamızı sağlar. Bu sadece XSLT'yi değiştirme meselesi.

Bu bizim için iyi çalışıyor. Bizim durumumuzda, salt okunur bir belgedir. Kullanıcı belgelerle etkileşimde bulunmuyor.

Ayrıca, XSLT kullanarak, sorunlu etki alanınıza (HTML) daha yakın çalışırsınız. Bunun her zaman iyi bir fikir olduğunu düşünürüm.

Son olarak, mevcut sisteminiz ÇALIŞIRSA, onu rahat bırakın. Mevcut kodunuzu çöpe atmanızı asla önermem. En baştan başlamış olsaydım, XSLT kullanırdım, ama senin durumunda, sahip olduğun şeyi kullanırdım.

Neye ihtiyacın olduğuna bağlı. Ana gücü, dönüşümün kolay sürdürülebilmesidir ve kendi ayrıştırıcınızı yazmak genellikle bunu ortadan kaldırır. Bununla birlikte, bazen bir sistem küçük ve basittir ve gerçekten "süslü" bir çözüme ihtiyaç duymaz. Kod tabanlı oluşturucunuz başka bir kodu değiştirmek zorunda kalmadan değiştirilebilir olduğu sürece, önemli değil.

XSL'nin çirkinliğine gelince, evet çirkin. Evet, alışmak biraz zaman alıyor. Ancak bir kez asıldığınızda (uzun IMO sürmemelidir), aslında sorunsuz bir seyirdir. Derlenmiş dönüşümler benim deneyimime göre oldukça hızlı çalışır ve kesinlikle bunlarda hata ayıklayabilirsiniz.

Hala XSLT'nin yararlı olabileceğine inanıyorum ama çirkin bir dil ve korkunç, okunamayan, sürdürülemez bir karmaşaya yol açabilir. Kısmen XML'in bir "dil" oluşturacak kadar insan tarafından okunabilir olmaması ve kısmen de XSLT'nin bildirimsel ve yordamsal olma arasında bir yerde sıkışmış olması nedeniyle. Bunu söyledikten sonra ve bence normal ifadelerle bir karşılaştırma yapılabilir, basit ve iyi tanımlanmış problemler söz konusu olduğunda kullanımı vardır.

Alternatif yaklaşımı kullanmak ve XML'i kodda ayrıştırmak da aynı derecede kötü olabilir ve XML'inizi doğrudan bir nesneye dönüştürecek bir tür XML sıralama / bağlama teknolojisini (Java'da JiBX gibi) gerçekten kullanmak istersiniz.

XSLT'yi bildirime dayalı bir tarzda kullanabiliyorsanız (bunun bildirici bir dil olduğu konusunda tamamen hemfikir olmasam da) o zaman kullanışlı ve anlamlı olduğunu düşünüyorum.

Veri / işleme katmanını işlemek için bir OO dili (benim durumumda C #) kullanan, ancak HTML yerine XML çıktısı veren web uygulamaları yazdım. Bu daha sonra müşteriler tarafından bir veri API'si olarak doğrudan kullanılabilir veya XSLT'ler tarafından HTML olarak işlenebilir. C #, yapısal olarak bu kullanımla uyumlu XML çıktısını aldığından, her şey çok düzgündü ve sunum mantığı açıklayıcı tutuldu. Takip etmek ve değiştirmek, etiketleri C # 'dan göndermekten daha kolaydı.

Ancak, XSLT düzeyinde daha fazla işlem mantığına ihtiyaç duyduğunuzda, işlevsel stili "elde etseniz" bile, karmaşık ve ayrıntılı hale gelir.

Elbette, bugünlerde muhtemelen bu web uygulamalarını bir RESTful arayüzü kullanarak yazmıştım - ve JSON gibi veri "dillerinin" XML'in geleneksel olarak XSLT tarafından dönüştürüldüğü alanlarda ilgi kazandığını düşünüyorum. Ancak şimdilik XSLT hala önemli ve kullanışlı bir teknolojidir.

XSLT'de çok zaman geçirdim ve bazı durumlarda faydalı bir araç olsa da, kesinlikle bir düzeltme olmadığını gördüm. Makine tarafından okunabilir XML girişi / çıkışı için veri çevirisi için kullanıldığında B2B amaçları için çok iyi çalışır. Sınırlarını ifade ederken yanlış yolda olduğunuzu düşünmüyorum. Beni en çok hayal kırıklığına uğratan şeylerden biri de XSLT uygulamalarındaki nüanslardı.

Belki de mevcut diğer biçimlendirme dillerinden bazılarına bakmalısınız. Jeff'in Stack Overflow ile ilgili bu konuyla ilgili bir makale yazdığına inanıyorum.

HTML İnsancıl bir Biçimlendirme Dili mi?

Ne yazdığına bir bakardım. Muhtemelen kendi şeylerinizi sıfırdan yazmak yerine, istediğiniz şeyi "kutudan çıkar çıkmaz" yapan veya en azından çok yakın olan bir yazılım paketi bulabilirsiniz.

Şu anda genel bir siteden veri toplamakla görevlendirildim (evet, biliyorum). Neyse ki xhtml ile uyumlu olduğundan, ihtiyacım olan verileri toplamak için xslt kullanabiliyorum. Ortaya çıkan çözüm okunabilir, temiz ve gerektiğinde değiştirilmesi kolaydır. Mükemmel!

XSLT'yi daha önce kullandım. 6 .xslt dosyalarının grubu (tek bir büyük dosyadan yeniden düzenlenmiş) C # ile yeniden yazmadan önce yaklaşık 2750 satırdı. C # kodu şu anda çok sayıda mantık içeren 4000 satırdır; Bunun XSLT'de ne yazması gerektiğini düşünmek bile istemiyorum.

Vazgeçtiğim nokta, XPATH 2.0'a sahip olmadığımın ilerlememe önemli ölçüde zarar verdiğini fark ettiğim zamandı.

Üç sorunuzu cevaplamak için:

1. XSLT'yi birkaç yıl önce bir kez kullandım.
2. XSLT'nin belirli durumlarda doğru çözüm olabileceğine inanıyorum. (Asla asla Deme)
3. Çoğunlukla 'basit' dönüşümler için yararlı olduğu yönündeki değerlendirmenize katılıyorum. Ancak XSLT'yi iyi anladığınız sürece, bir web sitesini HTML'ye dönüştürülmüş XML olarak yayınlamak gibi daha büyük görevlerde kullanmak için yapılması gereken bir durum olduğunu düşünüyorum.

Pek çok geliştiricinin XSLT'yi sevmemesinin nedeninin dayandığı temelde farklı paradigmayı anlamamaları olduğuna inanıyorum. Ancak işlevsel programlamaya olan son ilgiyle birlikte XSLT'nin geri dönüş yaptığını görebiliriz ...

Xslt'nin gerçekten parladığı yerlerden biri de raporlar üretmektir. İlk adımda rapor verilerini bir xml dosyası olarak dışa aktarırken ve ikinci adımda xslt kullanarak xml'den görsel rapor oluştururken 2 adımlı bir işlem buldum. Bu, ham verileri gerektiğinde bir doğrulama mekanizması olarak tutarken güzel görsel raporlar sağlar.

Önceki bir şirkette XML ve XSLT ile çok şey yaptık. Hem XML hem de XSLT büyük.

Evet bir öğrenme eğrisi var, ancak XML ile başa çıkmak için güçlü bir aracınız var. Ve XSLT'de XSLT'yi bile kullanabilirsiniz (bu bazen yararlı olabilir).

Performans da bir sorundur (çok büyük XML ile), ancak akıllı XSLT kullanarak bunun üstesinden gelebilir ve (oluşturulan) XML ile bazı ön işlemler yapabilirsiniz.

XSLT bilgisine sahip herhangi biri, derlenmediği için bitmiş ürünün görünümünü değiştirebilir.

Ben şahsen XSLT'yi seviyorum ve basitleştirilmiş sözdizimini vermek isteyebilirsiniz bir görünüm (açık şablonlar yok, sadece içine değer atmak için birkaç XSLT etiketi olan normal bir eski HTML dosyası), ancak bu herkes için değil.

Belki de yazarlarınıza basit bir Wiki veya Markdown arayüzü sunmak istiyorsunuz. Bunun için de kitaplıklar var ve XSLT sizin için çalışmıyorsa, belki XML onlar için de çalışmıyor.

XSLT, xml dönüşümünün hepsi bir arada değildir. Bununla birlikte, verilen bilgilere dayanarak sorununuza en iyi çözüm olup olmadığına veya daha verimli ve sürdürülebilir başka yaklaşımlar olup olmadığına karar vermek çok zordur. Yazarların içeriklerini basitleştirilmiş bir biçimde girebileceklerini söylüyorsunuz - hangi format? Metin kutuları? Ne tür bir html'ye dönüştürüyordunuz? XSLT'nin iş için doğru araç olup olmadığına karar vermek, bu dönüşümün özelliklerini daha ayrıntılı olarak bilmek yardımcı olacaktır.

XSLT'yi yalnızca XML belgelerinin ağaç yapısını değiştirmek için kullanmaktan zevk alıyorum. Metin işlemeyle ilgili herhangi bir şey yapmak ve bunu bir XML belgesine bir XSLT uygulamadan önce veya sonra çalıştırabileceğim özel bir betiğe aktarmayı külfetli buluyorum.

XSLT 2.0 çok daha fazla dizi işlevi içeriyordu, ancak bunun dile uygun olmadığını düşünüyorum ve XSLT 2.0'ın pek çok uygulaması yok.