it-swarm.asia

XSLT'yi kullanmak, öğrenmek veya önermek için iyi nedenler var mı?

Son 8 yıldır geliştiriciyim. XSLT'yi öncelikle XML'yi HTML'ye 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 yerini aldık. HTML, ASP.Net gibi programlama dilleri aracılığıyla rahatça oluşturulabilir. XML herhangi bir standart üst düzey dilde okunabilir ve değiştirilebilir. XSLT'de programlama biraz karmaşık olduğundan, herhangi biri en yeni programlama dilleri üzerinde çalışmayı tercih eder.

Şimdi sorum: XSLT, önceden geliştirilmiş XSLT'yi korumayı düşünmeden gelecekte önemli bir seçim olacak mı? Yeni programcılara XSLT eğitimi almasını önerebilir miyim?

28

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 derlenmesine gerek kalmadan 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 formatta sunmak için XSLT 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 ile oluşturulan HTML olan güzel bir tablo gösterir.

  • Bazı geliştirici yönelimli veya veri yönelimli web siteleri, web sitesinin sayfalarını programlı olarak kullanacaksa, XML'e erişim vermek isteyebilir². Özellikle HTML kodu her an değiştirilebildiğinden, HTML ayrıştırıcılarını kullanmaktan bir şekilde daha iyidir.

  • XSLT, web sitelerinde kullanıldığında, HTML ve arka plan kodları arasında katı bir ayırma yapılmasına izin verir; Başka bir soruya cevabım kısmındaki 1. maddeye bakınız.

XSLT gelecekte önemli bir seçim olacak mı? 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 birçok geliştirici XML'den ve XSLT'den nefret etmiyor.

XSLT'yi incelemek için yeni programcılar önerebilir misiniz? Elbette! Sadece XSLT, diğer yaklaşımların daha zor olacağı bazı durumlarda kullanılamaz, aynı zamanda XSLT'nin diğer dillerin sahip olmadığı çok spesifik bir yaklaşımı vardır.


¹ Bununla demek istediğim XML gerçekten insan tarafından okunamıyor: BT'de çalışmayan bir kişiden XML okumasını istersen dehşete düşecek.
² Web servisleri olduğunu biliyorum. Ancak bazen her sayfada, dinamik bir nesne oluşturmak, daha sonra XML'ye serileştirmek, daha sonra ya XSLT aracılığıyla HTML'ye dönüştürmek veya botun XML'ye doğrudan erişmesine izin vermek daha kolay ve daha basittir.

29
Arseni Mourzenko

XSLT hemen hemen öldü çünkü sadece birkaç meraklı hala kullanıyor. Bununla birlikte, bunun için gerçek bir alternatif yoktur. Semantik belgelerden HTML sayfalarının oluşturulması gibi yalnızca tek bir kullanım durumuna odaklanırsanız, daha iyi araçlar bulabilirsiniz. Kod oluşturma şablon motorları arıyorsanız, yine daha iyi araçlar var. Belge dönüştürme için de aynı şey geçerlidir.

Ancak, tüm bu kullanım örneklerini tüm platformlarda oldukça iyi destekleyen bir araç arıyorsanız, seçimler çok sınırlı olur. Zaten bir XML belgeniz varsa ve aracınızı kullanabilmek için bir şeye dönüştürmeniz gerekiyorsa, muhtemelen verilerinizi XSLT (veya XQuery) ile işlemek daha iyidir.

Her iki durumda da, XSLT'yi birkaç gün, belki haftalar içinde öğrenebilirsiniz. İlk elden bir deneyim yaşamanıza zarar vermez. Kendine bir şans ver. En azından bu tür bir deseni (kural tabanlı dönüşümler) daha sonra kullanmak üzere kafanızda saklamak için çaba sarf etmeye değer. Bu tek başına XSLT öğrenmeyi haklı çıkarır.

12
Michael

Evet.

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

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

9
pdr

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

XSLT, XML'i bir kaynak biçiminden diğerlerine dönüştürmek için çalıştığım yerlerde yaygın olarak kullanılır. XML'i XML olmayan çıktıya dönüştürmek için de kullanılabilir. Bunların çoğunu yapmadım ama PDF ve PostScript, diğerlerinin arasında) hedeflemek için yapıldığını duydum.

XSLT insan tarafından okunamaz. Meta bilgiler (etiketler) gerçek bilgiler (metin, xpath istekleri) üzerinde çok fazla yer tutar. İyi bir kod bir dokümantasyona benzemelidir ve bu XSLT için geçerli değildir. Harita araçları için iyi bir kalıcılık formatıdır.

İyi bir dönüştürme dili, dönüşüm sonucunun önizlemesine ve dönüşüm akışını (IF, ELSE, FOR, WHILE) aynı anda görüntülemesine izin vermelidir. bu sürdürülebilirlik için önemlidir. Bu yönüyle ilgili olarak Velocity veya GenearateXY XSLT'den daha iyidir. GenerateXY, önizleme ile akışı ayırdığı için biraz daha iyidir çünkü Velocity ile maalesef okunabilir bir akış sağlamak için önizleme girintisini kırmanız gerekir.

XSLT'deki tek iyi nokta, "xsl: template" öğelerini kullanarak ve hatta kötüye kullanarak modülerliğe önem vermesidir. Sorun, bir veri işleme dili (Java, C, ...) için iyi ama bir sunum dili için çok ikincil olmasıdır.

6
abraham

Programlama dillerinde her zaman seçim ve çeşitlilik olacaktır ve birinin diğerine tercih edilmesinin nedenleri işlevsellik, üretkenlik ve performans gibi nesnel kriterlerle olduğu kadar aşinalık ve moda ile ilgilidir. Hiç kimse modayı tahmin edemez, bu yüzden kimse programlama dillerinde gelecekteki eğilimleri tahmin edemez. Ancak XSLT için ilk öğrenme engellerini aşan ve bunun çok çeşitli görevler için son derece üretken bir araç olduğunu düşünen birçok insan var (muhtemelen şimdiye kadar tasarlanmaktan daha geniş bir çeşitlilik).

Birçok görev için XSLT'nin kullanıldığını görüyorum (ve kendim için kullandığım görevler), Java veya ASP işi yapmak için kod yazacağım) İşveren bütçenizin dehşet verici bir israfı olabilir, ancak belki = hayır = Java ve XSLT yazarken kötüdür).

6
Michael Kay

XSLT'nin en büyük başarısızlığı, verimli bir işlem için bir anda bellekte tutulması gereken belge miktarını en aza indirememesidir (herhangi bir gerçek uygulamada). Bunun yerine belgenin tamamı bir çeşit DOM temsili olarak okunur ve buna karşı işlem yapılır. Belge çok büyükse, bellek gereksinimleri de değişir. Yine de birçok stil sayfasının sadece mevcut etikete ve diğer birkaç etikete ihtiyacı vardır, ör. herhangi bir zamanda etiketin ataları ve böylece minimum bellek ve verimli akış ile işlenebilir.

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

4
Jess Holle

Nitekim

Öğrenmek ve kullanmak biraz hantal olduğu için bir şey muhtemelen bir gün XSLT'nin yerini alacak. Ancak şu anda, uygulamada esnek ve "saf" olan afaik için kullanılabilir şablon/dönüştürme dili yoktur.

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

  • Şablon kullanarak bir veriden HTML biçiminde içerik "oluşturabilirsiniz"
  • Bir xml biçiminden diğerine dönüştürebilirsiniz
  • Xml'yi başka bir biçime işleyebilir, belki bir alt kümeyi gösterebilirsiniz

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

Bir XHTML sayfasının içeriğini değiştirmek istiyorsak regexp kullanabiliriz, ancak regexp yapısal şeyler için dağınıktır. Dizeleri manipüle etmek için parlıyor, ancak bir şey için içindekiler tablosu oluşturmak veya farklı bir düzende sunmak için kullanmazdım.

Sıradaki ASP.Net. Yerleşimimizi asp sayfamıza koyarız ve dinamik parçalar için arkaya bazı kodlar ekleriz. Başka bir alternatif, mizanpaj kısmından vazgeçmek ve her şeyi bir veritabanı söylemek ve C # kullanarak istediğimiz çıktıyı oluşturmaktır.

İlk yaklaşımdaki sorun, açıklayıcı verilerden gerçek içeriğe gitmenin beceriksiz olmasıdır. Her harf için başlıklarla birlikte sunmak istediğiniz telefon numaralarını içeren bazı veri dosyalarınız varsa, toplam giriş sayısı vb. Gösterin, düzen dosyasında düzenin bir kısmına ve oluşturduğunuz kodda bazılarına sahip olmanız gerekir. . Başka bir seçenek web-grid koymak bir tür kullanmaktır Ben oldukça dağınık olanları bulmak ve aniden tüm yapmak istediğiniz zaman bazı belirli html çıktı vermek için frigging ızgara nasıl çalıştığını öğrenmek zorunda.

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 karıştırmanız gerekir. Ayrıca, yapılandırılmamış özyinelemeli belge tarzı içeriği düzgün bir şekilde işlemenin iyi bir yolu yoktur.

XSLT ile, olduğu gibi veya üst öğesinin bağlamında belirli bir etiket için bir şablon oluşturabilirsiniz, böylece örneğin başka bir şey tarafından ebeveynse, farklı şekilde işlenir.

Oldukça uzun başıboş bir cevap ama evet, açıklayıcı bir şablon dilinde büyük bir değer olduğunu düşünüyorum ve XSLT şimdiye kadar aldığımız en iyi ve en standartlaşmış cevap.

4
Homde

Nitekim, XSL'yi veri sunmak için başka bir dilden daha verimli kullanmak bence. Örneğin, XML'i PDF olarak XSL-FO kullanarak sunabilirsiniz ve her inç'i kontrol edebilirsiniz, ancak örneğin RDLC (.NET) ile çalışıyorsanız bunun çok zor olduğunu göreceksiniz. tam olarak ne istediğinizi sunmak.

XSL'de her elemanın kendi şablonu olduğu için evrim/düzeltme bile oldukça kolaydır. XSL uzantısının XSLT ve XSL-FO gibi daha önemli olduğunu düşünüyorum. Bu yüzden bu dil gelecekte de kullanılacak (ama bunun daha kararlı ve daha az karmaşık olacağını umuyorum).

3
yayaman

Bir Veri Entegrasyonu şirketi için çalışıyorum ve XSLT'yi tescilli araçlarımızla XML'den HTML/XML/Ascii'ye kadar harika bir çözüm olarak kullanıyoruz.

2
Bryan Harrington