Czy XSLT jest tego wart? [Zamknięte]

Jakiś czas temu zacząłem pracę nad projektem, w którym zaprojektowałem schemat XML w stylu html, tak aby autorzy mogli pisać swoje treści (materiały edukacyjne) w uproszczonym formacie, który następnie zostałby przekształcony w HTML za pomocą XSLT. Bawiłem się nim (walczyłem) przez chwilę i doszedłem do bardzo podstawowego poziomu, ale potem byłem zbyt zirytowany ograniczeniami, które napotykam (które mogły być ograniczeniami mojej wiedzy) i kiedy czytałem blog sugerujący porzucenie XSLT i po prostu napisz swój własny parser XML-to-dowolny w wybranym przez siebie języku, z niecierpliwością wskoczyłem do tego i wyszło świetnie.

Nadal nad tym pracuję do dziś ( właściwie mam nad tym teraz pracować, zamiast grać na SO ) i coraz częściej widzę rzeczy, które sprawiają, że myślę, że decyzja o porzuceniu XSLT była dobry.

Wiem, że XSLT ma swoje miejsce, ponieważ jest akceptowanym standardem i że jeśli każdy pisze własnych tłumaczy, 90% z nich trafi do TheDailyWTF . Ale biorąc pod uwagę, że jest to funkcjonalny język stylów zamiast stylu proceduralnego, z którym większość programistów jest zaznajomionych, dla kogoś rozpoczynającego projekt taki jak mój, czy poleciłbyś, aby poszedł ścieżką, którą zrobiłem, lub pozostawił ją z XSLT ?

Zalety XSLT:

• Specyficzne dla domeny XML, więc na przykład nie ma potrzeby cytowania literału XML w wynikach.
• Obsługuje XPath / XQuery, który może być dobrym sposobem na tworzenie zapytań dotyczących DOM, w taki sam sposób, w jaki wyrażenia regularne mogą być dobrym sposobem na tworzenie zapytań o ciągi znaków.
• Funkcjonalny język.

Wady XSLT:

• Może być nieprzyzwoicie rozwlekłe - nie musisz cytować dosłownego kodu XML, co w praktyce oznacza, że ​​musisz cytować kod. I nie w ładny sposób. Ale z drugiej strony, to nie jest dużo gorsze niż typowe SSI.
• Nie robi pewnych rzeczy, które większość programistów uważa za oczywiste. Na przykład manipulowanie strunami może być przykrym obowiązkiem. Może to prowadzić do „niefortunnych momentów”, kiedy nowicjusze projektują kod, a następnie gorączkowo przeszukują sieć w poszukiwaniu wskazówek, jak zaimplementować funkcje, które, jak przypuszczali, po prostu tam są i nie mają czasu na pisanie.
• Funkcjonalny język.

Nawiasem mówiąc, jednym ze sposobów uzyskania zachowania proceduralnego jest połączenie wielu przekształceń. Po każdym kroku masz zupełnie nowy DOM do pracy, który odzwierciedla zmiany w tym kroku. Niektóre procesory XSL mają rozszerzenia, które skutecznie robią to w jednej transformacji, ale nie pamiętam szczegółów.

Tak więc, jeśli twój kod jest w większości wyjściowy i nie ma dużo logiki, XSLT może być bardzo zgrabnym sposobem wyrażenia go. Jeśli jest dużo logiki, ale głównie formularzy wbudowanych w XSLT (wybierz wszystkie elementy, które wyglądają jak bla i dla każdego wyjścia bla), prawdopodobnie będzie to całkiem przyjazne środowisko. Jeśli przez cały czas masz ochotę myśleć w języku XML, wypróbuj XSLT 2.

W przeciwnym razie powiedziałbym, że jeśli Twój ulubiony język programowania ma dobrą implementację DOM obsługującą XPath i umożliwiającą budowanie dokumentów w użyteczny sposób, to korzystanie z XSLT ma kilka zalet. Wiązania do libxml2 i gdome2 powinny działać dobrze i nie ma nic złego w trzymaniu się języków ogólnego przeznaczenia, które dobrze znasz.

Domowe parsery XML są zwykle albo niekompletne (w takim przypadku pewnego dnia się nie utkniesz), albo niewiele mniejsze niż coś, co mogłeś dostać z półki (w takim przypadku prawdopodobnie marnujesz czas) i dają masz wiele możliwości wprowadzenia poważnych problemów z bezpieczeństwem związanych ze złośliwymi danymi wejściowymi. Nie pisz go, jeśli nie wiesz dokładnie, co zyskujesz dzięki temu. Co nie znaczy, że nie możesz napisać parsera dla czegoś prostszego niż XML jako format wejściowy, jeśli nie potrzebujesz wszystkiego, co oferuje XML.

Tyle negatywności!

Używam XSLT od dobrych kilku lat i naprawdę to uwielbiam. Kluczową rzeczą, którą musisz sobie uświadomić, jest to, że nie jest to język programowania, to język szablonów (i pod tym względem uważam, że jest nieopisanie lepszy od asp.net / spit).

XML jest de facto formatem danych wykorzystywanym obecnie w tworzeniu stron internetowych, czy to pliki konfiguracyjne, surowe dane, czy też reprezen tacje pamięci. XSLT i XPath zapewniają niezwykle potężny i bardzo wydajny sposób przekształcania tych danych w dowolny format wyjściowy, który od razu daje Ci aspekt MVC polegający na oddzieleniu prezentacji od danych.

Do tego dochodzi możliwości narzędziowe: czyszczenie przestrzeni nazw, rozpoznawanie odmiennych definicji schematów, scalanie dokumentów.

Z XSLT musi być lepiej niż opracowywanie własnych metod. Przynajmniej XSLT jest standardem i czymś, do czego możesz wynająć, a jeśli kiedykolwiek będzie to naprawdę problem dla twojego zespołu, to z natury pozwoli ci utrzymać większość zespołu w pracy tylko z XML.

Prawdziwy przypadek użycia: właśnie napisałem aplikację, która obsługuje dokumenty XML w pamięci w całym systemie i przekształca je w JSON, HTML lub XML zgodnie z żądaniem użytkownika końcowego. Otrzymałem dość losową prośbę o udostępnienie danych w formacie Excel. Były kolega zrobił coś podobnego programowo, ale wymagało to modułu kilku plików klasowych, a na serwerze był zainstalowany pakiet MS Office! Okazuje się, że Excel ma XSD: nową funkcjonalność z minimalnym wpływem na kod podstawowy w 3 godziny.

Osobiście uważam, że jest to jedna z najczystszych rzeczy, jakie napotkałem w swojej karierze i wierzę, że wszystkie jej widoczne problemy (debugowanie, manipulacja ciągami, struktury programistyczne) wynikają z błędnego zrozumienia narzędzia.

Oczywiście mocno wierzę, że warto.

Muszę przyznać, że jest to błąd, ponieważ zarabiam na życie uczę XSLT. Ale może warto omówić obszary, w których widzę moich uczniów pracujących. Ogólnie podzielili się na trzy grupy: publikacje, bankowość i internet.

Wiele dotychczasowych odpowiedzi można podsumować jako „nie nadaje się do tworzenia witryn internetowych” lub „w niczym nie przypomina języka X”. Wielu techników robi swoje kariery bez kontaktu z językami funkcjonalnymi / deklaratywnymi. Kiedy uczę, doświadczeni ludzie Java / VB / C / etc mają problemy z językiem (zmienne są zmiennymi w sensie algebry, a nie na przykład programowania proceduralnego). To wiele osób, które tutaj odpowiadają - nigdy nie radziłem sobie z Javą, ale nie zamierzam krytykować tego języka z tego powodu.

W wielu przypadkach jest to nieodpowiednie narzędzie do tworzenia stron internetowych - lepszy może być język programowania ogólnego przeznaczenia. Często muszę brać bardzo duże dokumenty XML i prezentować je w sieci; XSLT sprawia, że ​​jest to trywialne. Studenci, których widzę w tej przestrzeni, zwykle przetwarzają zbiory danych i prezentują je w sieci. XSLT z pewnością nie jest jedynym narzędziem, które można zastosować w tej przestrzeni. Jednak wielu z nich używa do tego DOM, a XSLT jest z pewnością mniej bolesny.

Studenci bankowości, których widzę, ogólnie używają skrzynki DataPower. Jest to urządzenie XML i służy do umieszczania między usługami „mówiącymi” różnymi dialektami XML. Transformacja z jednego języka XML na inny jest prawie trywialna w XSLT, a liczba studentów uczęszczających na moje kursy z tego zakresu rośnie.

Ostateczna grupa uczniów, którą widzę, pochodzi ze środowiska wydawniczego (jak ja). Ci ludzie mają tendencję do posiadania ogromnych dokumentów w formacie XML (wierz mi, publikowanie jako branża bardzo wkracza w XML - publikacje techniczne istnieją od lat, a publikacje branżowe osiągają ten poziom teraz). Te dokumenty muszą zostać przetworzone (przychodzi na myśl DocBook do ePub).

Ktoś powyżej skomentował, że skrypty mają zwykle mniej niż 60 wierszy lub stają się nieporęczne. Jeśli okaże się nieporęczny, istnieje prawdopodobieństwo, że programista nie ma o tym pojęcia - XSLT to zupełnie inny sposób myślenia niż wiele innych języków. Jeśli nie uzyskasz odpowiedniego nastawienia, to nie zadziała.

Z pewnością nie jest to język umierający (ilość pracy, którą otrzymuję, mówi mi o tym). W tej chwili trochę „utknęło”, dopóki Microsoft nie zakończy (bardzo późno) implementacji XSLT 2. Ale nadal istnieje i wydaje się, że z mojego punktu widzenia będzie się rozwijać.

Często używamy XSLT do takich celów, jak dokumentacja i udostępnianie użytkownikom niektórych skomplikowanych ustawień konfiguracyjnych.

Do dokumentacji używamy dużo DocBook, który jest formatem opartym na XML. To pozwala nam przechowywać naszą dokumentację i zarządzać nią z całym kodem źródłowym, ponieważ pliki są zwykłym tekstem. Dzięki XSLT możemy łatwo tworzyć własne formaty dokumentacji, co pozwala nam zarówno automatycznie generować zawartość w ogólny sposób, jak i zwiększać jej czytelność. Na przykład, kiedy publikujemy informacje o wersji, możemy utworzyć XML, który wygląda mniej więcej tak:

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

A następnie używając XSLT (który przekształca powyższe w DocBook) otrzymujemy ładne informacje o wydaniu (zazwyczaj PDF lub HTML), w których identyfikatory błędów są automatycznie łączone z naszym narzędziem do śledzenia błędów, błędy są grupowane według komponentów, a format wszystkiego jest idealnie spójny . Powyższy plik XML można wygenerować automatycznie, wysyłając zapytanie do naszego modułu śledzenia błędów, aby sprawdzić, co się zmieniło między wersjami.

Drugim miejscem, w którym uznaliśmy XSLT za użyteczne, jest nasz podstawowy produkt. Czasami, gdy łączymy się z systemami firm trzecich, musimy w jakiś sposób przetworzyć dane na złożonej stronie HTML. Przetwarzanie kodu HTML jest brzydkie, więc przekazujemy dane przez coś takiego jak TagSoup(który generuje odpowiednie zdarzenia SAX XML, co zasadniczo pozwala nam traktować HTML tak, jakby był poprawnie napisany XML), a następnie możemy uruchomić na nim trochę XSLT, aby przekształcić dane w "znany stabilny" format, z którym możemy faktycznie pracować . Oddzielenie tej transformacji do pliku XSLT oznacza, że ​​jeśli i kiedy zmieni się format HTML, sama aplikacja nie musi być aktualizowana, zamiast tego użytkownik końcowy może po prostu samodzielnie edytować plik XSLT lub możemy wysłać e-mail im zaktualizowany plik XSLT bez konieczności uaktualniania całego systemu.

Powiedziałbym, że w przypadku projektów internetowych istnieją obecnie lepsze sposoby obsługi strony widoku niż XSLT, ale XSLT ma zdecydowanie zastosowanie jako technologia. Nie jest to najłatwiejszy w użyciu język na świecie, ale na pewno nie jest martwy iz mojej perspektywy wciąż ma wiele dobrych zastosowań.

XSLT jest przykładem deklaratywnego języka programowania .

Inne przykłady deklaratywnych języków programowania obejmują wyrażenia regularne, Prolog i SQL. Wszystkie są bardzo ekspresyjne i kompaktowe, a także zwykle bardzo dobrze zaprojektowane i wydajne do zadania, do którego zostały zaprojektowane.

Jednak programiści generalnie nienawidzą takich języków, ponieważ różnią się one od bardziej popularnych obiektów obiektowych lub języków proceduralnych, że trudno się ich nauczyć i debugować. Ich zwarty charakter ogólnie sprawia, że ​​bardzo łatwo jest nieumyślnie wyrządzić wiele szkód.

Więc chociaż XSLT jest wydajnym mechanizmem scalania danych w prezentację, zawodzi w dziale łatwości użycia. Myślę, że dlatego tak naprawdę nie przyjęło się.

Pamiętam cały szum wokół XSLT, gdy standard został niedawno wydany. Cała ekscytacja związana z możliwością zbudowania całego interfejsu użytkownika HTML z „prostą” transformacją.

Spójrzmy prawdzie w oczy, jest trudny w użyciu, prawie niemożliwy do debugowania, często nieznośnie powolny. Efekt końcowy jest prawie zawsze dziwaczny i mniej niż idealny.

Prędzej odgryzę sobie nogę, niż użyję XSLT, podczas gdy istnieją lepsze sposoby na zrobienie czegoś. Nadal ma swoje miejsce, jest dobry do prostych zadań transformacji.

Używałem XSLT (a także XQuery) do różnych celów - do generowania kodu C ++ jako części procesu budowania, do tworzenia dokumentacji z komentarzy do dokumentów oraz w aplikacji, która musiała pracować z XML w ogóle, a XHTML w szczególności dużo . W szczególności generator kodu miał ponad 10000 linii kodu XSLT 2.0 rozrzuconych wokół kilkunastu oddzielnych plików (robił wiele rzeczy - nagłówki dla klientów, zdalne proxy / stuby, opakowania COM, opakowania .NET, ORM - żeby nazwać kilka). Odziedziczyłem go po innym facecie, który tak naprawdę nie rozumiał dobrze języka, a starsze części były w związku z tym niezłym bałaganem. Nowsze rzeczy, które napisaliśmy, były jednak w większości utrzymane przy zdrowych zmysłach i czytelne, i nie przypominam sobie żadnych szczególnych problemów z osiągnięciem tego. Z pewnością nie było to trudniejsze niż zrobienie tego dla C ++.

Mówiąc o wersjach, radzenie sobie z XSLT 2.0 zdecydowanie pomaga zachować zdrowy rozsądek, ale 1.0 nadal jest w porządku dla prostszych transformacji. W swojej niszy jest to niezwykle przydatne narzędzie, a produktywność, jaką można uzyskać dzięki pewnym funkcjom specyficznym dla domeny (co najważniejsze, dynamicznej wysyłce poprzez dopasowywanie szablonów) jest trudna do dopasowania. Pomimo postrzeganej wyrazistości składni opartej na XML XSLT, to samo w LINQ to XML (nawet w VB z literałami XML) było zwykle kilka razy dłuższe. Dość często jednak dostaje niezasłużony flakon z powodu niepotrzebnego używania XML w niektórych przypadkach w pierwszej kolejności.

Podsumowując: jest to niezwykle przydatne narzędzie, które można mieć w swojej skrzynce narzędziowej, ale jest bardzo wyspecjalizowane, więc jest dobre, o ile używasz go prawidłowo i zgodnie z przeznaczeniem. Naprawdę chciałbym mieć właściwą, natywną implementację XSLT 2.0 .NET.

Używam XSLT (z braku lepszej alternatywy), ale nie do prezentacji, tylko do transformacji:

1. Piszę krótkie transformacje XSLT, aby dokonać masowej edycji naszych plików pom.xml maven.

2. Napisałem potok transformacji do generowania schematów XML z XMI (Diagram UML). To działało przez chwilę, ale w końcu stało się zbyt skomplikowane i musieliśmy to wynieść za stodołę.

3. Użyłem transformacji do refaktoryzacji schematów XML.

4. Obejrzałem pewne ograniczenia w XSLT, używając go do generowania XSLT do prawdziwej pracy. (Czy kiedykolwiek próbowałeś napisać XSLT, który generuje dane wyjściowe przy użyciu przestrzeni nazw, które nie są znane do czasu uruchomienia?)

Wciąż do tego wracam, ponieważ lepiej radzi sobie z odwracaniem przetwarzanego XML-a niż inne metody, które wypróbowałem, które wydawały się niepotrzebnie stratne lub po prostu źle rozumiały XML. XSLT jest nieprzyjemny, ale uważam, że używanie Oxygen sprawia, że ​​jest to znośne.

To powiedziawszy, badam użycie Clojure (seplenienie) do wykonywania transformacji XML, ale nie dotarłem jeszcze wystarczająco daleko, aby wiedzieć, czy takie podejście przyniesie mi korzyści.

Osobiście użyłem XSLT w zupełnie innym kontekście. Gra komputerowa, nad którą wtedy pracowałem, zawierała mnóstwo stron UI zdefiniowanych za pomocą XML. Podczas poważnej refaktoryzacji krótko po wydaniu chcieliśmy zmienić strukturę tych dokumentów XML. Zmieniliśmy format wejściowy gry na znacznie lepszą strukturę uwzględniającą schematy.

XSLT wydawał się idealnym wyborem dla tego tłumaczenia ze starego formatu -> Nowy format. W ciągu dwóch tygodni miałem działającą konwersję ze starych na nowe dla naszych setek stron. Mogłem go również użyć do wydobycia wielu informacji na temat układu naszych stron interfejsu użytkownika. Utworzyłem listy komponentów, w które zostały osadzone, w które stosunkowo łatwo, a następnie użyłem XSLT do zapisania w naszych definicjach schematów.

Ponadto, wywodzący się z C ++, był to bardzo zabawny i interesujący język do opanowania.

Myślę, że jako narzędzie do tłumaczenia XML z jednego formatu na inny jest fantastyczne. Jednak nie jest to jedyny sposób na zdefiniowanie algorytmu, który przyjmuje XML jako dane wejściowe i coś wyprowadza . Jeśli twój algorytm jest wystarczająco złożony, fakt, że dane wejściowe są w formacie XML, staje się nieistotny dla twojego wyboru narzędzia - tj. Przeprowadź własne w C ++ / Pythonie / czymkolwiek.

Konkretnie dla twojego przykładu, wyobrażam sobie, że najlepszym pomysłem byłoby utworzenie własnej konwersji XML-> XML, która będzie zgodna z logiką biznesową. Następnie napisz tłumacza XSLT, który po prostu wie o formatowaniu i nie robi nic sprytnego. To może być niezły środek, ale to całkowicie zależy od tego, co robisz. Posiadanie tłumacza XSLT na wyjściu ułatwia tworzenie alternatywnych formatów wyjściowych - do druku, dla telefonów komórkowych itp.

Tak, często go używam. Używając różnych plików xslt, mogę używać tego samego źródła XML do tworzenia wielu plików HTML polyglot (X) (prezentujących te same dane na różne sposoby), źródła RSS, kanału Atom, pliku deskryptora RDF i fragmentu mapy witryny .

To nie jest panaceum. Są rzeczy, które robi dobrze i rzeczy, które nie robią dobrze, i tak jak wszystkie inne aspekty programowania, chodzi o użycie odpowiedniego narzędzia do odpowiedniej pracy. Jest to narzędzie, które warto mieć w swojej skrzynce narzędziowej, ale powinno się go używać tylko wtedy, gdy jest to konieczne.

Zdecydowanie poleciłbym to wytrzymać. Szczególnie jeśli używasz programu Visual Studio, które ma wbudowane narzędzia do edycji, przeglądania i debugowania XSLT.

Tak, jest to ból podczas nauki, ale większość bólu jest spowodowana zażyłością. Ból zmniejsza się, gdy uczysz się języka.

W3schools ma dwa szczególnie wartościowe artykuły: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Zauważyłem, że XSLT jest dość trudny w obsłudze.

Mam doświadczenie w pracy z systemem nieco podobnym do tego, który opisujesz. Moja firma zauważyła, że ​​dane, które zwracaliśmy z „środkowej warstwy”, były w formacie XML i że strony miały być renderowane w formacie HTML, który równie dobrze mógłby być XHTML, a ponadto słyszeli, że XSL jest standardem przekształcania między XML formaty. Tak więc „architekci” (przez co mam na myśli ludzi, którzy myślą głęboko o projektowaniu, ale najwyraźniej nigdy nie kodują) zdecydowali, że nasz pierwszy poziom zostanie zaimplementowany poprzez pisanie skryptów XSLT, które przekształcają dane w XHTML do wyświetlania.

Wybór okazał się katastrofalny. Okazuje się, że pisanie XSLT jest trudne. Dlatego wszystkie nasze strony były trudne do napisania i utrzymania. Lepiej by było, gdybyśmy użyli JSP (to było w Javie) lub podobnego podejścia, które wykorzystywało jeden rodzaj znaczników (nawiasy kątowe) dla formatu wyjściowego (HTML) i inny rodzaj znaczników (np. <% ... %>) dla metadanych. Najbardziej dezorientującą rzeczą w XSLT jest to, że jest napisany w XML i tłumaczy z XML do XML ... dość trudno jest zachować w pamięci wszystkie 3 różne dokumenty XML.

Twoja sytuacja jest nieco inna: zamiast tworzenia autorskiego każdej strony w XSLT, tak jak ja, wystarczy napisać JEDEN bit kodu w XSLT (kod do konwersji z szablonów do wyświetlenia). Ale wygląda na to, że napotkałeś ten sam rodzaj trudności, co ja. Powiedziałbym, że próba interpretacji prostego opartego na XML języka DSL (język specyficzny dla domeny), tak jak robisz, NIE jest jedną z mocnych stron XSLT. (Chociaż MOŻE wykonać pracę ... w końcu JEST TO Turing zakończone!)

Jeśli jednak to, co miałeś, było prostsze: masz dane w jednym formacie XML i chciałeś dokonać prostych zmian - nie pełnego opisu strony DSL, ale kilka prostych, prostych modyfikacji, to XSLT jest doskonałym narzędziem do tego celu. Jej deklaratywny (a nie proceduralny) charakter jest w rzeczywistości zaletą w tym celu.

- Michael Chermside

XSLT jest trudny w obsłudze, ale kiedy go pokonasz, będziesz miał bardzo dokładne zrozumienie DOM i schematu. Jeśli posiadasz również XPath, to jesteś na najlepszej drodze do nauki programowania funkcjonalnego, co pozwoli Ci poznać nowe techniki i sposoby rozwiązywania problemów. W niektórych przypadkach sukcesywna transformacja jest potężniejsza niż rozwiązania proceduralne.

Używam XSLT intensywnie do niestandardowego interfejsu w stylu MVC. Model jest „serializowany” do xml (nie przez xml serializaiton), a następnie konwertowany do html przez xslt. Przewaga nad ASP.NET polega na naturalnej integracji z XPath i bardziej rygorystycznych wymaganiach dotyczących poprawnego sformułowania (o wiele łatwiej jest wnioskować o strukturze dokumentu w xslt niż w większości innych języków).

Niestety, język ma kilka ograniczeń (na przykład możliwość przekształcenia wyjścia innej transformacji), co oznacza, że ​​czasami praca z nim jest frustrująca.

Niemniej jednak łatwo osiągalne, silnie wymuszone oddzielenie obaw, które zapewnia, nie jest czymś, co widzę teraz w innej technologii - więc w przypadku przekształceń dokumentów jest to nadal coś, co polecam.

Użyłem XML, XSD i XSLT w projekcie integracji między bardzo różniącymi się od siebie systemami DB gdzieś w 2004 roku. Musiałem nauczyć się XSD i XSLT od zera, ale nie było to trudne. Wspaniałą rzeczą w tych narzędziach było to, że umożliwiły mi pisanie niezależnego od danych kodu C ++, polegającego na XSD i XSLT w celu walidacji / weryfikacji, a następnie transformacji dokumentów XML. Zmień format danych, zmień dokumenty XSD i XSLT, a nie kod C ++, który wykorzystywał biblioteki Xerces.

Dla ciekawostek: główny plik XSD miał 150 KB, a średni rozmiar XSLT był <5 KB IIRC.

Inną wielką zaletą jest to, że XSD jest dokumentem specyfikacji, na którym opiera się XSLT. Obie działają w harmonii. A specyfikacje są obecnie rzadkością w tworzeniu oprogramowania.

Chociaż nie miałem większych problemów z nauczeniem się deklaratywnej natury XSD i XSLT, stwierdziłem, że inni programiści C / C ++ mieli duże problemy z dostosowaniem się do deklaratywnego sposobu. Kiedy zobaczyli, że to wszystko, ah proceduralne, mruknęli, teraz, kiedy rozumiem! I przystąpili (kalambur?) Do napisania proceduralnego XSLT! Chodzi o to, że musisz nauczyć się XPath i zrozumieć osie XML. Przypomina mi starych programistów C, którzy przyzwyczaili się do używania OO podczas pisania w C ++.

Użyłem tych narzędzi, ponieważ umożliwiły mi napisanie małej bazy kodu C ++, która została odizolowana od wszystkich, z wyjątkiem najbardziej podstawowych, modyfikacji struktury danych, a te ostatnie to zmiany struktury bazy danych. Mimo że wolę C ++ od jakiegokolwiek innego języka, użyję tego, co uważam za przydatne, aby zwiększyć długoterminową żywotność projektu oprogramowania.

Kiedyś myślałem, że XSLT to świetny pomysł. Mam na myśli, że to świetny pomysł.

Tam, gdzie się nie udaje, jest wykonanie.

Problem, który odkryłem z biegiem czasu, polegał na tym, że języki programowania w XML to po prostu zły pomysł. To sprawia, że ​​całość jest nieprzenikniona. W szczególności myślę, że XSLT jest bardzo trudny do nauczenia, kodowania i zrozumienia. XML oprócz aspektów funkcjonalnych sprawia, że ​​całość jest zbyt zagmatwana. Próbowałem się tego nauczyć około 5 razy w swojej karierze i po prostu się nie trzyma.

OK, możesz to „obrobić” - myślę, że częściowo o to chodziło w jego projekcie - ale to druga wada: wszystkie narzędzia XSLT na rynku są po prostu ... bzdury!

Specyfikacja XSLT definiuje XSLT jako „język służący do przekształcania dokumentów XML na inne dokumenty XML”. Jeśli próbujesz zrobić coś innego niż najbardziej podstawowe przetwarzanie danych w XSLT, prawdopodobnie są lepsze rozwiązania.

Warto również zauważyć, że możliwości przetwarzania danych XSLT można rozszerzyć w .NET za pomocą niestandardowych funkcji rozszerzeń:

• Dokumentacja MSDN
• CSharpFriends: samouczek

Prowadzę system dokumentacji online dla mojej firmy. Autorzy tworzą dokumentację w SGML (język podobny do XML). SGML jest następnie łączony z XSLT i przekształcany w HTML.

Dzięki temu możemy łatwo wprowadzać zmiany w układzie dokumentacji bez konieczności kodowania. To tylko kwestia zmiany XSLT.

To działa dobrze dla nas. W naszym przypadku jest to dokument tylko do odczytu. Użytkownik nie wchodzi w interakcję z dokumentacją.

Ponadto, używając XSLT, pracujesz bliżej swojej problematycznej domeny (HTML). Zawsze uważam, że to dobry pomysł.

Na koniec, jeśli twój obecny system DZIAŁA, zostaw go w spokoju. Nigdy nie sugerowałbym usunięcia istniejącego kodu. Gdybym zaczynał od zera, użyłbym XSLT, ale w twoim przypadku użyłbym tego, co masz.

Sprowadza się do tego, do czego go potrzebujesz. Jego główną zaletą jest łatwość utrzymania transformacji, a napisanie własnego parsera generalnie to unicestwia. Mając to na uwadze, czasami system jest mały i prosty i naprawdę nie potrzebuje „wyszukanego” rozwiązania. Tak długo, jak twój oparty na kodzie kreator jest wymienny bez konieczności zmiany innego kodu, nic wielkiego.

Jeśli chodzi o brzydotę XSL, tak, jest brzydki. Tak, trzeba się do tego przyzwyczaić. Ale kiedy już to zrozumiesz (nie powinno to zająć dużo czasu IMO), w rzeczywistości płynie gładko. Z mojego doświadczenia wynika, że ​​skompilowane transformacje działają dość szybko i na pewno można je debugować.

Nadal uważam, że XSLT może być przydatny, ale jest to brzydki język i może prowadzić do okropnego, nieczytelnego, nie do utrzymania bałaganu. Częściowo dlatego, że XML nie jest wystarczająco czytelny dla człowieka, aby stworzyć „język”, a częściowo dlatego, że XSLT utknął gdzieś pomiędzy deklaratywnością a procedurami. Powiedziawszy to i myślę, że porównanie można narysować za pomocą wyrażeń regularnych, ma ono swoje zastosowania, jeśli chodzi o proste, dobrze zdefiniowane problemy.

Korzystanie z alternatywnego podejścia i analizowanie XML w kodzie może być równie nieprzyjemne i naprawdę chcesz zastosować jakąś technologię krosowania / wiązania XML (taką jak JiBX w Javie), która przekształci Twój XML bezpośrednio w obiekt.

Jeśli możesz używać XSLT w stylu deklaratywnym (chociaż nie do końca zgadzam się, że jest to język deklaratywny), myślę, że jest to przydatne i wyraziste.

Napisałem aplikacje internetowe, które używają języka OO (w moim przypadku C #) do obsługi warstwy danych / przetwarzania, ale generują XML zamiast HTML. Może to być następnie wykorzystane bezpośrednio przez klientów jako interfejs API danych lub renderowane jako HTML przez XSLT. Ponieważ C # generował kod XML, który był strukturalnie zgodny z tym użyciem, wszystko było bardzo płynne, a logika prezentacji była deklaratywna. Łatwiej było śledzić i zmieniać niż wysyłanie tagów z C #.

Jednakże, gdy potrzebujesz więcej logiki przetwarzania na poziomie XSLT, staje się on zawiły i rozwlekły - nawet jeśli „uzyskasz” funkcjonalny styl.

Oczywiście w dzisiejszych czasach prawdopodobnie pisałbym te aplikacje internetowe przy użyciu interfejsu RESTful - i myślę, że „języki” danych, takie jak JSON, zyskują na znaczeniu w obszarach, w których XML był tradycyjnie przekształcany przez XSLT. Ale na razie XSLT jest nadal ważną i użyteczną technologią.

Spędziłem dużo czasu w XSLT i stwierdziłem, że chociaż jest to przydatne narzędzie w niektórych sytuacjach, zdecydowanie nie jest rozwiązaniem. Działa bardzo dobrze w celach B2B, gdy jest używany do tłumaczenia danych dla danych wejściowych / wyjściowych XML do odczytu maszynowego. Nie sądzę, abyś był na złej drodze w oświadczeniu o jego ograniczeniach. Jedną z rzeczy, które najbardziej mnie frustrowały, były niuanse w implementacjach XSLT.

Być może powinieneś przyjrzeć się innym dostępnym językom znaczników. Myślę, że Jeff napisał artykuł na ten temat dotyczący przepełnienia stosu.

Czy HTML jest humanitarnym językiem znaczników?

Rzucę okiem na to, co napisał. Prawdopodobnie możesz znaleźć pakiet oprogramowania, który robi to, co chcesz „po wyjęciu z pudełka” lub przynajmniej bardzo blisko, zamiast pisać własne rzeczy od podstaw.

Obecnie mam za zadanie pobieranie danych z witryny publicznej (tak, wiem). Na szczęście jest zgodny ze standardem xhtml, więc mogę użyć xslt do zebrania potrzebnych danych. Powstały roztwór jest czytelny, czysty i łatwy do zmiany w razie potrzeby. Idealny!

Używałem wcześniej XSLT. Grupa 6 plików xslt (refaktoryzowanych z jednego dużego) liczyła około 2750 wierszy na długo przed tym, jak przepisałem go w C #. Kod C # to obecnie 4000 wierszy zawierających dużo logiki; Nie chcę nawet myśleć o tym, co mogłoby się zabrać do napisania w XSLT.

Moment, w którym się poddałem, był wtedy, gdy zdałem sobie sprawę, że brak XPATH 2.0 znacznie szkodził moim postępom.

Aby odpowiedzieć na trzy pytania:

1. Użyłem XSLT kilka lat temu.
2. Wierzę, że XSLT może być właściwym rozwiązaniem w pewnych okolicznościach. (Nigdy nie mów nigdy)
3. Zgadzam się z twoją oceną, że jest to przydatne głównie do „prostych” przekształceń. Ale myślę, że dopóki dobrze rozumiesz XSLT, warto użyć go do większych zadań, takich jak publikowanie strony internetowej w formacie XML przekształconym w HTML.

Uważam, że powodem, dla którego wielu programistów nie lubi XSLT, jest to, że nie rozumieją zasadniczo odmiennego paradygmatu, na którym jest oparty. Ale w związku z niedawnym zainteresowaniem programowaniem funkcjonalnym możemy zauważyć, że XSLT powróci ...

Jednym z miejsc, w których xslt naprawdę się wyróżnia, jest generowanie raportów. Zauważyłem, że jest to proces dwuetapowy, z pierwszym krokiem eksportującym dane raportu do pliku xml, a drugim krokiem generującym raport wizualny z xml przy użyciu xslt. Pozwala to na tworzenie ładnych raportów wizualnych, jednocześnie zachowując surowe dane jako mechanizm walidacji, jeśli zajdzie taka potrzeba.

W poprzedniej firmie dużo zrobiliśmy z XML i XSLT. Zarówno XML, jak i XSLT są duże.

Tak, jest krzywa uczenia się, ale masz potężne narzędzie do obsługi XML. Możesz nawet używać XSLT na XSLT (co czasami może być przydatne).

Wydajność jest również problemem (w przypadku bardzo dużych plików XML), ale można temu zaradzić za pomocą inteligentnego XSLT i wykonać pewne wstępne przetwarzanie z (wygenerowanym) XML.

Każdy, kto zna XSLT, może zmienić wygląd gotowego produktu, ponieważ nie jest on skompilowany.

Osobiście lubię XSLT i możesz chcieć nadać wygląd uproszczonej składni (bez wyraźnych szablonów, tylko zwykły stary plik HTML z kilkoma tagami XSLT do wypluwania wartości), ale po prostu nie jest dla wszystkich.

Może po prostu chcesz zaoferować swoim autorom prosty interfejs Wiki lub Markdown. Istnieją również biblioteki do tego, a jeśli XSLT nie działa dla ciebie, być może XML też nie działa.

XSLT nie jest końcem transformacji XML. Jednak na podstawie podanych informacji bardzo trudno jest ocenić, czy byłoby to najlepsze rozwiązanie problemu, czy też istnieją inne, bardziej wydajne i możliwe do utrzymania podejście. Mówisz, że autorzy mogliby wprowadzić swoje treści w uproszczonym formacie - w jakim formacie? Pola tekstowe? Na jaki rodzaj HTML był konwertowany? Aby ocenić, czy XSLT jest odpowiednim narzędziem do tego zadania, pomocne byłoby bardziej szczegółowe poznanie cech tej transformacji.

Lubię używać XSLT tylko do zmiany struktury drzewa dokumentów XML. Uważam za niewygodne robienie czegokolwiek związanego z przetwarzaniem tekstu i przenoszenie tego do niestandardowego skryptu, który mogę uruchomić przed lub po zastosowaniu XSLT do dokumentu XML.

XSLT 2.0 zawierało znacznie więcej funkcji tekstowych, ale myślę, że nie pasuje do tego języka i nie ma wielu implementacji XSLT 2.0.