Czy XSLT jest tego wart? [zamknięte]

Tyle negatywności!

Używam XSLT od dobrych kilku lat i szczerze go kocham. Najważniejsze, co musisz sobie uświadomić, to to, że to nie jest 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 tworzenia stron internetowych dzisiaj, czy to pliki konfiguracyjne, surowe dane lub w reprsentacji pamięci. XSLT i XPath dają ogromnie potężny i bardzo wydajny sposób aby przekształcić te dane w dowolny format wyjściowy, który chcesz, natychmiast daje ten aspekt MVC oddzielenia prezentacji od danych.

Są też możliwości użytkowe: wymywanie przestrzeni nazw, rozpoznawanie różnych definicji schematów, łączenie dokumentów.

It must be better to deal with XSLT than developing your own-house methods. Przynajmniej XSLT to standard i coś do czego można zatrudnić, a jeśli to kiedyś będzie problemem dla Twojego zespołu to bardzo natura pozwoli Ci utrzymać większość Twojego 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 się w JSON, HTML lub XML zgodnie z żądaniem użytkownika końcowego. Miałem dość przypadkową prośbę o podanie danych Excela. Były kolega zrobił coś podobnego programowo ale wymagało to modułu kilku plików klasowych i że serwer miał zainstalowany MS Office! Okazuje się, że Excel ma XSD: nowa funkcjonalność przy minimalnym wpływie kodu bazowego w ciągu 3 godzin.

Osobiście uważam, że jest to jedna z najczystszych rzeczy, z którymi spotkałem się w mojej karierze, i wierzę, że wszystkie oczywiste problemy (debugowanie, manipulacja łańcuchami, struktury programistyczne) sprowadzają się do błędnego zrozumienia narzędzia.

Oczywiście, mocno wierzę, że jest "warto".

Muszę tu przyznać stronniczość, ponieważ uczę XSLT na życie. Ale może warto zatuszować obszary, w których moi uczniowie pracują. Dzielą się na trzy grupy: wydawniczą, bankową i internetową.

Wiele odpowiedzi do tej pory można streścić jako "to nie jest dobre do tworzenia stron internetowych" lub "nie ma to jak język X". Wielu techników przechodzi przez swoją karierę bez kontaktu z funkcyjnymi / deklaratywnymi językami. Kiedy uczę, doświadczony Java/VB/C / etc ludzie mają problemy z językiem (zmienne są zmiennymi w sensie algebry, a nie programowania proceduralnego np.). To jest wiele osób, które tutaj odpowiadają - nigdy nie miałem do czynienia z Javą, ale nie będę się trudził krytykować języka z tego powodu.

W wielu okolicznościach jest to nieodpowiednie narzędzie do tworzenia stron internetowych - lepszy może być język programowania ogólnego przeznaczenia. Często muszę wziąć bardzo duże dokumenty XML i przedstawić je na web; XSLT czyni to banalnym. Uczniowie, których widzę w tej przestrzeni, zazwyczaj przetwarzają zbiory danych i prezentują je w Internecie. XSLT z pewnością nie jest jedynym odpowiednim narzędziem w tej przestrzeni. Jednak wielu z nich używa do tego DOM i XSLT jest z pewnością mniej bolesne.

STUDENCI bankowości, których widzę, używają w ogóle Skrzynki DataPower. Jest to urządzenie XML i służy do siedzenia między usługami "mówiącymi" różnymi dialektami XML. Transformacja z jednego języka XML do drugiego jest prawie trywialne w XSLT i liczba studentów uczęszczających na moje kursy na ten temat rośnie.

Ostatni zestaw uczniów, który widzę, pochodzi z zaplecza wydawniczego (jak ja). Ci ludzie mają zazwyczaj ogromne dokumenty w XML (uwierz mi, publikowanie jako przemysł jest coraz bardzo do XML-wydawnictwa techniczne Jest tam od lat i handlu publishing jest coraz tam teraz). Dokumenty te muszą być przetwarzane (DocBook to ePub przychodzi na myśl tutaj).

Ktoś powyżej skomentował, że skrypty mają tendencję do poniżej 60 linijek lub stają się nieporęczne. Jeśli stanie się to nieporęczne, możliwe, że programista nie wpadł na pomysł - XSLT to zupełnie inny sposób myślenia niż wiele innych języków. Jeśli nie masz nastawienia, to nie zadziała.

To na pewno nie jest umierający język (ilość pracy, którą dostaję, mówi mi o tym). W tej chwili jest to trochę "zablokowane", dopóki Microsoft nie zakończy swojej (bardzo późnej) implementacji XSLT 2. Ale nadal tam jest i wydaje się być silny z mojego punktu widzenia.

Używamy XSLT szeroko do takich rzeczy, jak dokumentacja, i sprawiając, że niektóre złożone ustawienia konfiguracyjne są łatwe do obsługi przez użytkownika.

Do dokumentacji używamy dużo DocBook, który jest formatem opartym na XML. To pozwala nam przechowywać i zarządzać naszą dokumentacją z całym naszym kodem źródłowym, Ponieważ pliki są zwykłym tekstem. Dzięki XSLT możemy z łatwością tworzyć własne formaty dokumentacji, co pozwala nam zarówno na autogenerację treści w sposób ogólny, jak i uczynienie jej bardziej czytelną. Na przykład, kiedy publikujemy uwagi do wydania, 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 za pomocą XSLT (który przekształca powyższe do DocBook) kończymy z nice release notes (Zwykle PDF lub HTML), gdzie identyfikatory błędów są automatycznie połączone z naszym trackerem błędów, błędy są pogrupowane według komponentów, a format wszystkiego jest idealnie spójny. Powyższy XML może być generowany automatycznie, pytając nasz bug tracker o to, co zmieniło się między wersjami.

The other place gdzie uznaliśmy XSLT za przydatny jest w rzeczywistości w naszym głównym produkcie. Czasami podczas interakcji z systemami innych firm musimy w jakiś sposób przetwarzać dane na złożonej stronie HTML. Parsowanie HTML jest brzydkie, więc przekazujemy dane przez coś w rodzaju TagSoup (który generuje odpowiednie zdarzenia SAX XML, zasadniczo pozwalając nam radzić sobie z HTML tak, jakby był poprawnie napisany XML), a następnie możemy uruchomić jakiś XSLT przeciwko niemu, aby przekształcić dane w "znany stabilny" format, który możemy faktycznie pracować z. Oddzielając tę transformację do pliku XSLT, oznacza to, ż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 edytować plik XSLT siebie, lub możemy wysłać im e-mail zaktualizowany plik XSLT bez konieczności uaktualniania całego systemu.

Powiedziałbym, że w przypadku projektów internetowych istnieją lepsze sposoby obsługi strony widoku niż dzisiaj XSLT, ale jako technologia zdecydowanie są zastosowania dla XSLT. Nie jest najprostszy język na świecie w użyciu, ale na pewno nie jest martwy, a z mojej perspektywy nadal ma wiele dobrych zastosowań.

XSLT jest przykładem deklaratywnego języka programowania .

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

Więc o ile XSLT jest wydajnym mechanizmem scalania danych w prezentację, to nie sprawdza się w dziale łatwości użycia. Myślę, że dlatego tak naprawdę się nie załapało.

Pamiętam cały szum wokół XSLT, kiedy standard został niedawno wydany. Wszystkie emocje związane z możliwością zbudowania całego interfejsu HTML za pomocą "prostej" transformacji.

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 są lepsze sposoby na rzeczy. Wciąż ma swoje miejsca, dobre do prostych zadań transformacji.

Używałem XSLT (a także XQuery) szeroko do różnych rzeczy - do generowania kodu C++ w ramach procesu budowania, do tworzenia dokumentacji z komentarzy doc, a w ramach aplikacji, która musiała pracować z XML w ogóle i XHTML w szczególności dużo. Generator kodu był w szczególności ponad 10 000 linii kodu XSLT 2.0 rozrzuconych po kilkunastu osobnych plikach ( zrobił wiele rzeczy - nagłówki dla klientów, remotowanie proxy/stubów, wrappery COM, wrappery. NET, ORM - aby wymienić kilka). Odziedziczyłem go po innym facecie, który nie do końca dobrze rozumiał język, a starsze kawałki były w związku z tym całkiem bałagan. Nowsze rzeczy, które napisaliśmy, były jednak w większości utrzymywane 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 jest nadal w porządku dla prostszych przekształceń. W swojej niszy jest niezwykle poręczne narzędzie i produktywność, którą uzyskujesz dzięki określonym funkcjom domenowym (co najważniejsze, dynamiczna wysyłka za pomocą dopasowania szablonu), są trudne do dopasowania. Pomimo postrzeganej słowności składni XSLT opartej na XML, to samo w LINQ do XML (nawet w VB z literałami XML) było zwykle kilka razy dłuższe. Dość często jednak dostaje niezasłużony flack z powodu niepotrzebnego używania XML w niektórych przypadkach w pierwszej kolejności.

Podsumowując: jest to niezwykle przydatne narzędzie, aby mieć w swoim toolbox, ale jest bardzo specjalistyczny, więc jest dobry, o ile używasz go prawidłowo i zgodnie z jego przeznaczeniem. Szkoda, że nie ma odpowiedniej, natywnej implementacji. NET dla XSLT 2.0.

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

1. Piszę krótkie transformacje XSLT do masowych edycji na naszym maven pom.pliki xml.

2. Napisałem rurociąg przekształceń do generowania schematów XML z XMI (diagram UML). Zadziałało przez jakiś czas, ale w końcu stało się zbyt skomplikowane i musieliśmy go wyjąć za stodołę.

3. Użyłem transformacji do refactor XML Schematy.

4. Obejrzałem pewne ograniczenia w XSLT, używając go do generowania XSLT, aby wykonać prawdziwą pracę. (Próbowałeś kiedyś napisać XSLT, który tworzy wyjście przy użyciu przestrzeni nazw, które nie są znane przed uruchomieniem?)

Wracam do niego, ponieważ robi to lepiej-potknięcie przetwarzanego XML niż inne podejścia, które próbowałem, które wydawały się niepotrzebnie stratne lub po prostu źle zrozumiane XML. XSLT jest nieprzyjemne, ale uważam, że używanie tlenu sprawia, że jest znośny.

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

Osobiście używałem XSLT w zupełnie innym kontekście. Gra komputerowa, nad którą pracowałem w tym czasie używała ton stron interfejsu użytkownika zdefiniowanych za pomocą XML. Podczas dużej refaktorii krótko po wydaniu chcieliśmy zmienić strukturę tych dokumentów XML. Sprawiliśmy, że format wejściowy gry jest zgodny z dużo lepszą strukturą i schematem.

XSLT wydawało się idealnym wyborem dla tego tłumaczenia ze starego formatu - > nowego formatu. W ciągu dwóch tygodni miałem pracującą konwersję ze starego na nowy dla naszych setek stron. Byłem również w stanie użyć go do wyodrębnienia wielu informacji na temat układu naszych stron interfejsu użytkownika. Stworzyłem listy, które komponenty zostały osadzone w które stosunkowo łatwo, które następnie użyłem XSLT do zapisu do naszych definicji schematu.

Ponadto, wywodzący się z C++, był bardzo zabawnym i interesującym językiem do opanowania.

Myślę, że jako narzędzie do tłumaczenia XML z jednego formatu do drugiego jest fantastyczne. Jednak nie jest to jedyny sposób na zdefiniowanie algorytm, który pobiera XML jako wejście i wyjście coś. Jeśli twój algorytm jest wystarczająco złożony, fakt, że dane wejściowe to XML, staje się nieistotny dla Twojego wyboru narzędzia - tj. roll your own in C++ / Python / whatever.

Specyficznie dla Twojego przykładu, wyobrażam sobie, że najlepszym pomysłem byłoby stworzenie własnego XML - >XML convert, który podąża za Twoją logiką biznesową. Następnie napisz Tłumacz XSLT, który po prostu wie o formatowaniu i nie robi nic mądrego. To może być ładny środek ziemia, ale to całkowicie zależy, 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, używam go często. Korzystając z różnych plików xslt, mogę użyć tego samego źródła XML, aby utworzyć wiele plików HTML polyglot (X) (prezentujących te same dane na różne sposoby), kanał RSS, kanał Atom, plik deskryptora RDF i fragment mapy witryny.

To nie jest panaceum. Są rzeczy, które robią dobrze, a rzeczy, które nie robią dobrze, i podobnie jak wszystkie inne aspekty programowania, chodzi o użycie odpowiedniego narzędzia do właściwej pracy. To narzędzie, które warto mieć w swojej skrzynce narzędziowej ale powinien być używany tylko wtedy, gdy jest to właściwe.

Zdecydowanie polecam, aby trzymać go. Szczególnie jeśli używasz visual studio, które ma wbudowane narzędzia do edycji, przeglądania i debugowania dla XSLT.

Tak, to ból podczas nauki, ale większość bólu jest związana z znajomością. Ból maleje, gdy uczysz się języka.

W3schools ma dwa artykuły, które są szczególnie warto: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Uważam, że XSLT jest dość trudny do pracy.

Mam doświadczenie w pracy nad systemem nieco podobnym do tego, który opisujesz. Moja firma zauważyła, że dane, które zwracamy z "warstwy środkowej", były w XML, a strony miały być renderowane w HTML, który równie dobrze mógłby być XHTML, plus słyszeli, że XSL jest standardem przekształcania między formatami XML. Więc "architekci" (przez co mam na myśli ludzi, którzy myślą głęboko projektują myśli, ale najwyraźniej nigdy nie kodują) zdecydowaliśmy, że nasza warstwa frontowa zostanie zaimplementowana przez pisanie skryptów XSLT, które przekształcają dane w XHTML do wyświetlania.

Wybór okazał się katastrofalny. XSLT, jak się okazuje, to ból do pisania. I tak wszystkie nasze strony były trudne do napisania i utrzymania. Znacznie lepiej byłoby użyć JSP (tak było w Javie) lub podobnego podejścia, które używało jednego rodzaju znaczników (nawiasy kątowe) dla formatu wyjściowego (HTML) i innego rodzaju znaczników (jak ) dla metadanych. Najbardziej mylącą rzeczą w XSLT jest to, że jest napisany w XML i tłumaczy się z XML na XML... trudno jest utrzymać wszystkie 3 różne dokumenty XML prosto w umyśle.

Twoja sytuacja jest nieco inna: zamiast tworzenia każdej strony w XSLT, tak jak ja, musisz napisać tylko jeden bit kodu w XSLT (kod do konwersji z szablonów na wyświetlanie). Ale wygląda na to, że napotkałeś te same trudności,co ja. Powiedziałbym, że próba interpretacji prostego DSL opartego na XML (Domain specific language), jak to robisz, nie jest jedną z mocnych stron XSLT. (Chociaż może wykonać zadanie... w końcu to Turing kompletny!)

Jeśli jednak to, co miałeś było prostsze: masz dane w jednym formacie XML i chciałeś wprowadzić w nim proste zmiany - Nie pełny opis strony DSL, ale kilka prostych prostych modyfikacji, to XSLT jest doskonałym narzędziem do tego celu. Charakter deklaratywny (a nie proceduralny) jest właściwie korzyść w tym celu.

-- Michael Chermside

XSLT jest trudne do pracy z, ale gdy go zdobyć będziesz miał bardzo dokładne zrozumienie DOM i schematu. Jeśli również XPath, to na drodze do nauki programowania funkcyjnego, a to będzie narażone na nowe techniki i sposoby rozwiązywania problemów. W niektórych przypadkach następująca transformacja jest silniejsza niż rozwiązania proceduralne.

Używam XSLT intensywnie, dla niestandardowego front-endu w stylu MVC. Model jest "serializowany" do xml (nie przez XML serializaiton), a następnie konwertowany do html przez xslt. Przewaga nad ASP.NET leży w naturalnej integracji z XPath i bardziej rygorystycznych wymaganiach w zakresie poprawnej formy (dużo łatwiej jest rozumować o strukturze dokumentów w xslt niż w większości innych języków).

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

Niemniej jednak łatwo osiągalne, silnie wymuszone oddzielenie obaw, które udziela, nie jest czymś, co widzę inną technologię dostarczającą w tej chwili - więc dla przekształceń dokumentów nadal jest to coś, co polecam.

Użyłem XML, XSD i XSLT w projekcie integracji między bardzo podobnymi systemami DB gdzieś w 2004 roku. Musiałem nauczyć się XSD i XSLT od podstaw, ale to nie było trudne. Wspaniałą rzeczą w tych narzędziach było to, że pozwoliło mi pisać niezależny od danych kod C++, opierając się na XSD i XSLT, aby zweryfikować / zweryfikować, a następnie przekształcić dokumenty XML. Zmień format danych, Zmień dokumenty XSD i XSLT, a nie kod C++, który wykorzystywał biblioteki Xerces.

Dla zainteresowania: główny XSD wynosił 150KB, a średni rozmiar XSLT wynosił

Inną wielką korzyścią jest to, że XSD jest dokumentem specyfikacji, na którym opiera się XSLT. Obaj pracują w harmonii. A specyfikacje są rzadkie w rozwoju oprogramowania w dzisiejszych czasach.

Chociaż nie miałem zbyt wiele problemów z Poznaniem deklaratywnej natury XSD i XSLT, odkryłem, że inni programiści C / C++ mieli duże problemy z dostosowaniem się do deklaratywnej drogi. Kiedy zobaczyli, że to jest to, ach, mruknęli, teraz to Rozumiem! I kontynuowali (kalambur?) do napisania XSLT! Chodzi o to, że musisz nauczyć się XPath i zrozumieć osie XML. Przypomina mi dawnych programistów C przystosowujących się do używania OO podczas pisania C++.

Użyłem tych narzędzi, ponieważ pozwoliły mi napisać małą bazę kodu C++, która była odizolowana od wszystkich, ale najbardziej podstawowych modyfikacji struktury danych, a te ostatnie były zmianami struktury DB. Mimo, że wolę C++ niż jakikolwiek inny język, użyję tego, co rozważ, że jest przydatny do skorzystania z długoterminowej rentowności projektu oprogramowania.

Kiedyś myślałem, że XSLT to świetny pomysł. To świetny pomysł.

Gdzie nie powiedzie się wykonanie.

Problem, który odkryłem w czasie było to, że języki programowania w XML są po prostu zły pomysł. To sprawia, że wszystko jest nieprzeniknione. Szczególnie myślę, że XSLT jest bardzo trudne uczyć się, kod i zrozumieć. XML na dodatek do aspektów funkcjonalnych po prostu sprawia, że cała sprawa jest zbyt myląca. Próbowałem się tego nauczyć około 5 razy w mojej karierze i po prostu nie stick.

OK, można by to 'narzynać' -- myślę, że po części o to chodziło w jego projektowaniu -- ale to już druga porażka: wszystkie narzędzia XSLT na rynku są, po prostu ... cholera!

Specyfikacja XSLT definiuje XSLT jako "język do przekształcania dokumentów XML w inne dokumenty XML". Jeśli próbujesz zrobić cokolwiek poza najbardziej podstawowym przetwarzaniem 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: Tutorial

Prowadzę internetowy system dokumentacji dla mojej firmy. Pisarze tworzą dokumentację w SGML (języku podobnym do xml ). SGML jest następnie łączony z XSLT i przekształcany w HTML.

Pozwala nam to na łatwe wprowadzanie zmian 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ą.

Również za pomocą XSLT, pracujesz bliżej swojej domeny problemowej (HTML). Zawsze uważam to za dobry pomysł.

Na koniec, jeśli twój obecny system działa, zostaw go w spokoju. Nigdy nie sugerowałbym niszczenia Twojego istniejącego kodu. Gdybym zaczynał od zera, użyłbym XSLT, ale w Twoim przypadku użyłbym tego, co masz.

Wszystko sprowadza się do tego, czego potrzebujesz. Jego główną siłą jest łatwa konserwacja transformacji, a pisanie własnego parsera ogólnie to niszczy. Z tym powiedziawszy, czasami system jest mały i prosty i naprawdę nie potrzebuje "wymyślnego" rozwiązania. Tak długo, jak Twój konstruktor oparty na kodzie jest wymienny bez konieczności zmiany innego kodu, nic wielkiego.

Co do brzydoty XSL, to tak jest brzydki. Tak, trzeba się przyzwyczaić. Ale kiedy już się przyzwyczaisz (IMO nie powinno to potrwać długo), to właściwie płynna żegluga. Skompilowane transformacje działają dość szybko z mojego doświadczenia i z pewnością 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, niemożliwego 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 tkwi gdzieś pomiędzy deklaratywnym a proceduralnym. Mimo to, i myślę, że porównanie można narysować z wyrażeniami regularnymi, ma swoje zastosowania, jeśli chodzi o proste, dobrze zdefiniowane problemy.

Wykorzystanie alternatywnego podejścia i parsowanie XML w kod może być równie paskudny i naprawdę chcesz użyć jakiejś technologii łączenia/wiązania XML (takiej jak JiBX w Javie), która przekonwertuje Twój XML prosto do obiektu.

Jeśli możesz używać XSLT w stylu deklaratywnym (chociaż nie do końca zgadzam się, że jest to język deklaratywny), to uważam, że jest on użyteczny i wyrazisty.

Napisałem aplikacje internetowe, które używają języka OO (w moim przypadku C#) do obsługi warstwy danych / przetwarzania, ale wyprowadzają XML zamiast HTML. Może to być wykorzystane bezpośrednio przez klientów jako API danych lub renderowane jako HTML przez XSLTs. Ponieważ C# wyprowadzał XML, który był strukturalnie zgodny z tym zastosowaniem, wszystko było bardzo gładkie, i logika prezentacji została zachowana deklaratywnie. Łatwiej było śledzić i zmieniać niż wysyłać znaczniki z C#.

Jednak, ponieważ wymagasz więcej logiki przetwarzania na poziomie XSLT, staje się ona zawiła i gadatliwa - nawet jeśli "otrzymasz" styl funkcjonalny.

Oczywiście w dzisiejszych czasach prawdopodobnie napisałbym te aplikacje internetowe za pomocą interfejsu RESTful - i myślę, że "języki" danych, takie jak JSON, zyskują na popularności w obszarach, w których XML został tradycyjnie przekształcony przez XSLT. Ale dla teraz 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, to zdecydowanie nie jest to naprawa. Działa bardzo dobrze dla celów B2B, gdy jest używany do tłumaczenia danych do odczytu maszynowego XML wejścia / wyjścia. Nie sądzę, że jesteś na złej drodze w swoim oświadczeniu o jego ograniczeniach. Jedną z rzeczy, które najbardziej mnie sfrustrowały, były niuanse w implementacjach XSLT.

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

Czy HTML jest humanitarnym językiem znaczników?

Rzuciłbym 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 skrobanie danych ze strony publicznej(tak, wiem). Na szczęście jest zgodny z xhtml, więc jestem w stanie użyć xslt do zbierania danych, których potrzebuję. Uzyskane rozwiązanie jest czytelne, czyste i łatwe do zmiany w razie potrzeby. Idealnie!

Używałem już XSLT. Grupa 6 .pliki xslt (refakturowane z jednego dużego) były około 2750 linii na długo przed przepisaniem go w C#. Kod C# to obecnie 4000 linii zawierających dużo logiki; nie chcę nawet myśleć o tym, co trzeba by było napisać w XSLT.

Punktem, w którym się poddałem, jest to, że zdałem sobie sprawę, że brak XPATH 2.0 znacząco rani moje postępy.

Aby odpowiedzieć na twoje trzy pytania:

1. używałem kiedyś XSLT kilka lat temu.
2. wierzę, że XSLT może być właściwym rozwiązaniem w pewnych okolicznościach. (Never say never)
3. zgadzam się z Twoją oceną, że jest to głównie przydatne dla "prostych" przekształceń. Ale myślę, że tak długo, jak dobrze rozumiesz XSLT, nie ma przypadku do wykorzystania go do większych zadań, takich jak publikowanie strony internetowej jako XML przekształcony w HTML.

I believe the reason many deweloperzy nie lubią XSLT, ponieważ nie rozumieją zasadniczo innego paradygmatu, na którym się opiera. Ale z niedawnym zainteresowaniem programowaniem funkcyjnym możemy zobaczyć, jak XSLT powraca...

Jednym z miejsc, gdzie xslt naprawdę świeci, jest generowanie raportów. Odkryłem, że proces 2 krok, z pierwszym krokiem eksportowania danych raportu jako plik xml, a drugi krok generowania wizualnego raportu z xml za pomocą xslt. Pozwala to na ładne raporty wizualne przy jednoczesnym zachowaniu surowych danych jako mechanizmu walidacji, jeśli zajdzie taka potrzeba.

W poprzedniej firmie robiliśmy wiele z XML i XSLT. Zarówno XML jak i XSLT big.

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

Wydajność jest również problemem (z bardzo dużym XML), ale można sobie z tym poradzić za pomocą smart XSLT i zrobić pewne wstępne przetwarzanie za pomocą (generowanego) XML.

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

Osobiście lubię XSLT i możesz chcieć dać uproszczoną składnię wygląd (bez jawnych szablonów, tylko zwykły stary plik HTML z kilkoma znacznikami XSLT, aby wypluć do niego wartości), ale to po prostu nie jest dla wszystkich.

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

XSLT nie jest end-all be-all transformacji xml. Jednak bardzo trudno jest ocenić na podstawie podanych informacji, czy byłoby to najlepsze rozwiązanie twojego problemu lub czy istnieją inne bardziej wydajne i możliwe do utrzymania podejścia. Mówisz, że autorzy mogą wprowadzać swoje treści w uproszczonym formacie - jaki format? Pola tekstowe? Na jaki rodzaj html go konwertowałeś? Aby ocenić, czy XSLT jest właściwym narzędziem do tego zadania, pomocne byłoby poznanie funkcji tego transformacja bardziej szczegółowo.

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

XSLT 2.0 zawiera dużo więcej funkcji łańcuchowych, ale myślę, że nie jest to dobre dopasowanie do języka, a nie ma wielu implementacji XSLT 2.0.