XSLT'yi kullanmak, öğrenmek veya önermek için herhangi bir iyi sebep var mı? [kapalı]

Son 8 yıldır geliştiriciyim. XSLT'yi öncelikle XML'i HTML'e dönüştürmek için kullandık. Ayrıca XML'den XML'e dönüşüm için de kullandık.

Ama şimdi her şeyin yerine geçeceğiz. HTML, ASP.Net gibi programlama dilleri aracılığıyla rahatça oluşturulabilir. XML, herhangi bir standart yüksek seviyeli dilde okunabilir ve yönetilebilir. XSLT'deki programlama biraz karmaşık olduğundan, herhangi biri en son programlama dillerinde çalışmayı tercih eder.

Şimdi benim sorum: XSLT, halihazırda geliştirilen XSLT'yi sürdürmenin gerçeğini göz önünde bulundurmadan gelecekte önemli bir seçim olacak mı? XSLT'yi incelemeleri için yeni programcıları önerebilir miyim?

XSLT'nin iyi bir seçim olabileceği bazı önemli durumlar vardır:

• ETL ( Extract, Transform, Load ) yazılımı bazı durumlarda XSLT kullanabilir. Örneğin, hem çıkarılan verilerin hem de yüklenecek verilerin XML biçiminde olması ve uygulamanın yeniden derlenmesi gerekmeden dönüştürmenin değiştirilebileceği durumlarda iyi bir seçim olabilir.

• XML'de veri depolayan bazı uygulamalar, bu verileri insan tarafından okunabilir bir biçimde sunmak için XSLT'yi kullanır¹. Örneğin, Windows Live Messenger, iletilerin izini XML olarak depolar, ancak geçmişi WLM'de açtığınızda, aslında XSLT aracılığıyla oluşturulan HTML olan hoş bir tablo gösterir.

• Bazı geliştirici odaklı veya veri odaklı web siteleri, web sitesinin sayfalarını programlı olarak kullanmak istiyorsa, XML’e erişim vermek isteyebilir. Özellikle HTML kodu her an değiştirilebildiği için, HTML ayrıştırıcıları kullanmaktan bir şekilde daha iyidir.

• XSLT, web sitelerinde kullanıldığında, HTML ile kod arkası arasında katı bir ayrım yapılmasına olanak tanır; bu, kod arkası için bir geliştirici ve HTML / CSS işleri için başka bir geliştirici işe almayı sağlar. Başka bir soruya cevabımdaki 1. maddeye bakınız .

XSLT gelecekte önemli bir seçim mi olacak? Bu bugün önemli bir seçim değil ve XSLT kullanımının zamanla artacağından şüpheliyim. Bunun nedenini görmezden geliyorum, ancak çoğu geliştirici XML'i sevmiyor ve XSLT'den nefret ediyor.

XSLT'yi incelemeleri için yeni programcıları önerebilir misiniz? Emin! Diğer yaklaşımların daha zor olacağı bazı durumlarda yalnızca XSLT değil, XSLT diğer dillerin sahip olmadığı çok özel bir yaklaşıma da sahiptir.

^{This Bununla, yani XML'in gerçekten insan tarafından okunamadığı anlamına gelir: BT'de çalışmayan bir kişiden XML okumasını istemeniz durumunda, dehşete düşecektir.
² Web servisleri olduğunu biliyorum. Ancak bazen, her sayfada, dinamik bir nesne oluşturmak, sonra onu XML'e serileştirmek, sonra XSLT aracılığıyla HTML'ye dönüştürmek veya botun doğrudan XML'e erişmesine izin vermek daha kolay ve daha kolaydır.}

XSLT oldukça ölüdür, çünkü sadece birkaç kişi onu kullanıyor. Ancak bunun için gerçek bir alternatif yok. Örneğin, HTML sayfalarının anlamsal belgelerden görüntülenmesi gibi tek bir kullanım durumuna odaklanırsanız, daha iyi araçlar bulursunuz. Kod oluşturma şablon motorlarını ararsanız, yine daha iyi araçlar var. Belge dönüşümü için aynı.

Ancak, tüm bu kullanım durumlarını tüm platformlarda oldukça iyi destekleyen bir araç arıyorsanız, seçimler çok sınırlıdır. Zaten bir XML belgeniz varsa ve aracınızı kullanabilecek bir şeye dönüştürmek zorunda kalırsanız, muhtemelen verilerinizi XSLT (veya XQuery) ile işlemeniz daha iyi olacaktır.

Her iki durumda da, XSLT'yi birkaç gün, belki haftalar içinde öğrenebilirsiniz. İlk elden bir deneyim edinmeniz sizi incitmez. Kendine bir şans ver. En azından bu tür kalıbı (kural tabanlı dönüşümler) daha sonra kullanmak üzere kafanızda saklamak için harcanan çabaya değer. Bu tek başına XSLT öğrenmeyi haklı çıkarır.

Hmm Koddan HTML oluşturan üst düzey API'lerin herhangi bir XSLT'yi "başlık altında" kullanıp kullanmadığını merak ediyorum ...

XSLT, XML'i bir kaynak biçiminden diğerine dönüştürmek için çalıştığımda yoğun olarak kullanılıyor. XML'i XML olmayan çıktıya dönüştürmek için de kullanılabilir. Bunların çoğunu yapmadım, ancak PDF ve PostScript'i hedef almak için yapıldığını duydum.

Evet.

İyi bir örnek verelim: sürekli entegrasyonda birim test raporları. Çoğu birim test ve kod kapsamı programları, yalnızca okunamayan XML tonları verir. Ancak birkaç basit XSLT ile, aynı verilerden bir düzine yararlı rapor oluşturabilirsiniz. Ve diğer insanlar bu raporları tekrar kullanabilir.

Şimdi bunları CI aracının eklentiler için kullandığı dilde yazabilirsiniz, ancak o dili bilmiyorsanız (örneğin, siz bir .NET geliştiricisiyseniz, Jenkins kullanarak) o zaman öğrenmenize gerek yoktur. Bir XML dosyasına zaten XSLT uygulayan bir eklenti kullanın ve bazı yararlı XSLT'ler yazın.

Programlama dillerinde her zaman seçim ve çeşitlilik olacaktır ve birisinin diğerine tercih edilmesinin nedenleri, işlevsellik, verimlilik ve performans gibi nesnel ölçütlerle olduğu kadar aşinalık ve moda ile de ilgilidir. Hiç kimse modayı tahmin edemez, dolayısıyla hiç kimse programlama dillerinde gelecekteki eğilimleri tahmin edemez. Ancak, XSLT için ilk öğrenme engellerini aşan ve çok çeşitli görevler için (muhtemelen başa çıkacak şekilde tasarlandığından daha geniş bir çeşitlilik) son derece üretken bir araç olduğunu gören birçok insan var.

XSLT'nin kullanıldığını (ve bunu kendim için yaptığım görevlerin) kullandığını görüyorum, işi yapmak için Java veya ASP kodu yazmak işveren bütçenizin korkunç bir israfı olacak. Ama belki de değil, eğer Java yazarken iyi ve XSLT yazarken kötü olursanız.

XSLT insan tarafından okunamaz. Meta bilgi (etiketler) gerçek bilginin üzerinde çok fazla yer tutar (metin, xpath istekleri). İyi bir kod bir dokümantasyona benzemelidir ve bu XSLT için geçerli değildir. Haritalama araçları için oldukça iyi bir kalıcılık biçimidir.

İyi bir dönüşüm dili, dönüşüm sonucunu önizlemeye ve dönüşüm akışını (IF, ELSE, FOR, WHILE) aynı anda görmeye izin vermelidir. bu sürdürülebilirlik için önemlidir. Bu açıdan, Hız veya GenearateXY , XSLT'den daha iyidir. GenerateXY, önizlemeyi ve akışı birbirinden ayırdığı için biraz daha iyidir. Velocity ile ne yazık ki, okunabilir bir akış sağlamak için önizleme girintisini kırmanız gerekir.

XSLT'deki tek iyi nokta, "xsl: template" elemanlarını kullanarak ve hatta kötüye kullanarak modülerliği önemsemesidir. Bununla ilgili sorun, bir veri işleme dili (Java, C, ...) için iyi, ancak bir sunum dili için çok ikincil olmasıdır.

Aslında

Bir şeyler muhtemelen bir gün XSLT'nin yerini alacak, çünkü öğrenmesi ve kullanması biraz zahmetli. Ancak, şu anda uygulanmasında esnek ve "saf" olan bir afaik şablonu / dönüşüm dili bulunmamaktadır.

XSL-T birkaç farklı amaç için kullanılabilir:

• Bir şablon kullanarak bir veriden söz konusu içeriği HTML formatında "oluşturabilirsiniz"
• Bir xml biçiminden diğerine dönüştürebilirsiniz
• Xml'yi başka bir biçime sokabilir, belki bir alt kümeyi gösterebilirsiniz

Temel olarak tüm bunlar aynıdır, ancak bir XML veri dosyasının diğerine dönüşümü. Şimdi XSLT yerine kullanabileceğimiz farklı araçlara bakalım.

Eğer bir XHTML sayfasının içeriğini değiştirmek istiyorsak, regexp'i kullanabiliriz, ancak regexp yapısal şeyler için dağınıktır. Dizeleri işlemek için parlıyor, ancak bir şey için bir içindekiler tablosu oluşturmak ya da farklı bir düzende sunmak için kullanmıyorum.

Sırada ASP.Net var. Düzenimizi asp sayfamıza koyduk ve dinamik parçalar için arkasına bazı kodlar ekledik. Başka bir alternatif, pafta bölümünden bahsetmek ve bir veri tabanından her şeyi üretmek ve istenen çıktımızı oluşturmak için C # kullanmaktır.

İlk yaklaşımdaki sorun, tanımlayıcı verilerden gerçek içeriğe geçmenin sakar olmasıdır. Her harf için başlıkları göstermek istediğiniz telefon numaralarını içeren bazı veri dosyalarınız varsa, mizanpaj dosyasındaki mizanpajın bir kısmını ve oluşturduğunuz kodun bazılarını içermesi gereken toplam giriş sayısını gösterir. . Başka bir seçenek ise bazı web-grid formlarını kullanmaktır. Bunları oldukça karışık buluyorum ve birdenbire, tüm istediğiniz veriyi verilen belirli bir html çıktısı almak istediğinizde frigging gridin nasıl çalıştığını öğrenmek zorundasınız.

Tamamen dinamik olmak kesinlikle bir seçenektir ama bu da oldukça sakar. LINQ gibi bir şey kullandığınız en iyi durumda bile, programlama kodunu çıktı ile oldukça çirkin bir şekilde birleştirmeniz gerekir. Ayrıca, html'nin genellikle olduğu yapılandırılmamış özyinelemeli belge stili içeriği düzgün bir şekilde işlemenin iyi bir yolu yoktur.

XSLT ile, belli bir etiket için bir şablon hazırlayabilirsiniz, örneğin ana öğesinin içeriğinde olduğu gibi veya ana öğesi bağlamında.

Oldukça uzun bir başıboş cevap ama evet, bence tanımlayıcı bir şablon dilinde büyük bir değer var ve XSLT şu ana kadar elde ettiğimiz en iyi ve en standart olanı.

XSLT'nin en büyük başarısızlığı, etkin işlem için bir anda bellekte tutulması gereken belge miktarını en aza indirememesidir (herhangi bir gerçek uygulamada). Bunun yerine belgenin tamamı DOM temsiline okundu ve buna karşı işlem yapıldı. Belge çok büyükse, bellek gereksinimleri de öyledir. Bununla birlikte, birçok stil sayfası açıkça yalnızca geçerli etikete ve birkaç diğerine, örneğin etiketin atalarına, herhangi bir zamanda ihtiyaç duyduğundan, minimum bellek ve verimli akışla işlenebilir.

Evet, dil açısından garip, ama bu sadece giriş engeliydi. XSLT'yi biliyorsanız, alternatiflerden genellikle daha kolaydır - ancak büyük belgeleriniz (veya aynı anda işlenen çok sayıda belge varsa), XSLT'nin bellek etkisi genellikle diğer, daha fazla zaman alan alternatifleri zorlar.

Aslında, veri sunarken XSL'yi başka bir dilden kullanmanın daha verimli olduğunu düşünüyorum. Örneğin, XSL-FO kullanarak bir XML olarak XML sunabilir ve her inç'i kontrol edebilirsiniz, ancak örneğin RDLC (.NET) ile çalışıyorsanız, tam olarak ne istediğinizi sunmanın çok zor olduğunu göreceksiniz.

Evrim / düzeltme bile, XSL'de olduğu gibi, her bir elemanın kendi şablonu vardır. XSL'nin uzatılmasının XSLT ve XSL-FO gibi daha önemli olduğunu düşünüyorum. Bu nedenle bu dil gelecekte hala kullanılacak (ancak daha kararlı ve daha az karmaşık olacağını umuyorum).

Veri Entegrasyonu şirketi için çalışıyorum ve XML'i HTML / XML / Ascii'ye dahil eden mükemmel bir çözüm olarak XSLT'yi özel araçlarımızla birlikte kullanıyoruz.