Czy są jakieś dobre powody, aby używać, uczyć się lub polecać XSLT? [Zamknięte]

Jestem programistą przez ostatnie 8 lat. Używaliśmy XSLT przede wszystkim do przekształcania XML-a na HTML. Użyliśmy go również do transformacji XML na XML.

Ale teraz mamy wszystko na wymianę. HTML można wygodnie tworzyć za pomocą języków programowania, takich jak ASP.Net. XML można czytać i modyfikować w dowolnym standardowym języku wysokiego poziomu. Ponieważ programowanie w XSLT jest trochę skomplikowane, każdy wolałby pracować nad najnowszymi językami programowania.

Teraz moje pytanie: czy XSLT będzie znaczącym wyborem w przyszłości, nie biorąc pod uwagę faktu utrzymania już opracowanego XSLT? Czy mogę polecić nowych programistów do nauki XSLT?

Istnieje kilka ważnych przypadków, w których XSLT może być dobrym wyborem:

• Oprogramowanie ETL ( Extract, Transform, Load ) może w niektórych przypadkach używać XSLT. Na przykład może być dobrym wyborem, gdy zarówno wyodrębnione dane, jak i dane do załadowania są w formacie XML, a transformacja może zostać zmieniona bez konieczności ponownej kompilacji aplikacji.

• Niektóre aplikacje przechowujące dane w formacie XML używają XSLT do prezentacji tych danych w formacie czytelnym dla człowieka¹. Na przykład Windows Live Messenger przechowuje ślad wiadomości jako XML, ale kiedy otworzysz historię w samym WLM, pokaże ci ładną tabelę, która w rzeczywistości jest HTML zbudowana przez XSLT.

• Niektóre witryny zorientowane na programistów lub zorientowane na dane mogą chcieć zapewnić dostęp do XML, jeśli ich celem jest programowe korzystanie ze stron witryny². Jest to w jakiś sposób przyjemniejsze niż używanie parserów HTML, zwłaszcza, że ​​kod HTML można zmienić w dowolnym momencie.

• XSLT, stosowany w witrynach internetowych, umożliwia ścisłe oddzielenie kodu HTML od kodu, co umożliwia zatrudnienie programisty odpowiedzialnego za kod i innego programistę do obsługi HTML / CSS. Zobacz punkt 1 mojej odpowiedzi na inne pytanie .

Czy XSLT będzie znaczącym wyborem w przyszłości? Cóż, dzisiaj nie jest to znaczący wybór i wątpię, aby użycie XSLT wzrosło z czasem. Ignoruję powód tego, ale wielu programistów nie lubi XML i nienawidzi XSLT.

Czy możesz polecić nowych programistów do nauki XSLT? Pewnie! Nie tylko XSLT może być używany w niektórych okolicznościach, gdy inne podejścia byłyby trudniejsze, ale także XSLT ma bardzo specyficzne podejście, którego nie mają inne języki.

^{¹ Rozumiem przez to, że XML nie jest tak naprawdę czytelny dla człowieka: jeśli poprosisz osobę, która nie pracuje w IT, o odczytanie XML, będzie przerażony.
² Wiem, że istnieją usługi sieciowe. Czasami jednak na każdej stronie jest po prostu łatwiej i prościej zbudować obiekt dynamiczny, a następnie serializować go do formatu XML, a następnie przekształcić go w HTML za pomocą XSLT lub pozwolić botowi na bezpośredni dostęp do XML.}

XSLT jest prawie martwy, ponieważ wciąż korzysta z niego tylko kilku entuzjastów. Jednak nie ma na to realnej alternatywy. Jeśli skupisz się tylko na jednym przypadku użycia, takim jak na przykład renderowanie stron HTML z dokumentów semantycznych, znajdziesz lepsze narzędzia. Jeśli szukasz silników szablonów do generowania kodu, znowu są lepsze narzędzia. To samo dotyczy transformacji dokumentów.

Ale jeśli szukasz narzędzia, które całkiem dobrze obsługuje wszystkie te przypadki użycia na wszystkich platformach, możliwości są bardzo ograniczone. Jeśli masz już dokument XML i musiałbyś go przekształcić w coś, aby móc korzystać z narzędzia, prawdopodobnie lepiej jest po prostu przetwarzać swoje dane za pomocą XSLT (lub XQuery).

Tak czy inaczej, możesz nauczyć się XSLT w ciągu kilku dni, a może tygodni. Nie zaszkodzi ci doświadczyć z pierwszej ręki. Po prostu spróbuj. Warto przynajmniej przechowywać w pamięci tego rodzaju wzorzec (transformacje oparte na regułach) do późniejszego wykorzystania. Już samo to uzasadnia naukę XSLT.

Hmm, zastanawiam się, czy interfejsy API wysokiego poziomu, które tworzą HTML z kodu, używają XSLT „pod maską” ...

XSLT jest szeroko stosowany tam, gdzie pracuję, aby przekształcić XML z jednego formatu źródłowego do wielu innych. Można go także użyć do przekształcenia danych XML w dane wyjściowe inne niż XML. Nie zrobiłem wiele z tego, ale słyszałem o tym, że robiono to, aby celować między innymi w pliki PDF i PostScript.

Tak.

Weźmy dobry przykład: raporty z testów jednostkowych w ciągłej integracji. Większość programów do testowania jednostek i pokrywania kodu po prostu generuje tony nieczytelnego XML. Ale za pomocą kilku prostych XSLT możesz utworzyć kilkanaście przydatnych raportów z tych samych danych. Inne osoby mogą ponownie wykorzystać te raporty.

Teraz możesz napisać je w dowolnym języku, którego narzędzie CI używa do wtyczek, ale jeśli nie znasz tego języka (powiedzmy, że jesteś programistą .NET i używasz Jenkinsa), nie musisz się go uczyć. Po prostu użyj wtyczki, która już stosuje XSLT do pliku XML i napisz kilka przydatnych XSLT.

Zawsze będzie wybór i różnorodność języków programowania, a powody, dla których ktoś wybiera się przed innymi, są w równym stopniu związane ze znajomością i modą, jak z obiektywnymi kryteriami, takimi jak funkcjonalność, wydajność i wydajność. Nikt nie jest w stanie przewidzieć mody, więc nikt nie może przewidzieć przyszłych trendów w językach programowania. Ale jest wiele osób, które przekroczyły początkowe bariery uczenia się dla XSLT i przekonały się, że jest to niezwykle produktywne narzędzie do bardzo szerokiej gamy zadań (być może o wiele szerszej niż kiedykolwiek była przeznaczona do rozwiązania).

W przypadku wielu zadań, do których używam XSLT (i zadań, których używam dla siebie), pisanie kodu Java lub ASP do wykonania tej pracy byłoby przerażającym marnotrawstwem budżetu pracodawcy. Ale może nie, jeśli jesteś dobry w pisaniu w Javie, a zły w pisaniu XSLT.

XSLT nie jest czytelny dla człowieka. Meta-informacje (tagi) zajmują zbyt dużo miejsca nad rzeczywistymi informacjami (tekst, żądania xpath). Dobry kod powinien wyglądać jak dokumentacja, a nie jest tak w przypadku XSLT. Jest to raczej dobry format trwałości dla narzędzi mapujących.

Dobry język transformacji powinien pozwalać na podgląd wyniku transformacji i jednoczesne przeglądanie przepływu transformacji (JEŻELI, WKRÓTCE, FOR, KIEDY). jest to ważne dla łatwości konserwacji. Jeśli chodzi o ten aspekt, Velocity lub GenearateXY są lepsze niż XSLT. Generowanie XY jest nawet nieco lepsze, ponieważ oddziela podgląd i przepływ, podczas gdy z Velocity musiałbyś niestety przerwać wcięcie podglądu, aby zapewnić czytelny przepływ.

Jedyną zaletą XSLT jest to, że dba o modułowość, używając, a nawet nadużywając elementów „xsl: template”. Problem polega na tym, że jest dobry dla języka przetwarzania danych (Java, C, ...), ale bardzo pomocny dla języka prezentacji.

W rzeczy samej

Pewnego dnia coś prawdopodobnie zastąpi XSLT, ponieważ jest to trochę kłopotliwe w nauce i użytkowaniu. Jednak obecnie nie jest dostępny żaden język szablonów / transformacji, który jest tak elastyczny i „czysty” w swojej implementacji.

XSL-T może być wykorzystywany do kilku różnych celów:

• Możesz „tworzyć” treści w formacie HTML, powiedzmy, z danych przy użyciu szablonu
• Możesz konwertować z jednego formatu xml na inny
• Możesz manipulować xml w innym formacie, być może pokazać podzbiór

Zasadniczo wszystkie są tym samym, jednak transformacja jednego pliku danych XML w inny. Teraz spójrzmy na kilka różnych narzędzi, których moglibyśmy użyć zamiast XSLT.

Gdybyśmy chcieli manipulować treścią powiedzmy stronę XHTML, moglibyśmy użyć wyrażenia regularnego, ale wyrażenie regularne jest nieporządne w przypadku elementów strukturalnych. Świeci do manipulowania ciągami, ale nie użyłbym go do stworzenia spisu treści dla czegoś lub przedstawienia go w innym układzie.

Dalej jest ASP.Net. Umieszczamy nasz układ na stronie asp i wstawiamy trochę kodu dla części dynamicznych. Inną alternatywą jest rezygnacja z części układu i generowanie wszystkiego, na przykład bazy danych i używanie C # do tworzenia pożądanych wyników.

Problem z pierwszym podejściem polega na tym, że niezdarne jest przejście od danych opisowych do rzeczywistej treści. Jeśli masz plik danych zawierający numery telefonów, które chcesz przedstawić wraz z nagłówkami dla każdej litery, pokaż całkowitą liczbę wpisów itp., Musisz mieć część układu w pliku układu, a część w generowanym kodzie . Inną opcją jest użycie jakiejś formy umieszczania siatki w sieci. Uważam, że są dość niechlujne i nagle musisz nauczyć się, jak działa ta cholerna siatka, gdy wszystko, co chciałeś zrobić, to wydrukować jakiś konkretny plik HTML z danymi.

Całkowicie dynamiczna jest z pewnością opcją, ale jest to również dość niezdarne. Nawet w najlepszym przypadku, gdy używasz czegoś takiego jak LINQ, będziesz musiał przeplatać kod programowania z wyjściem w dość brzydki sposób. Nie ma też dobrego sposobu na właściwą obsługę nieustrukturyzowanej rekursywnej treści w stylu dokumentu, którą zwykle jest HTML.

Za pomocą XSLT możesz po prostu utworzyć szablon dla określonego znacznika, tak jak jest lub w kontekście jego elementu nadrzędnego, więc jest renderowany inaczej, jeśli na przykład jest inny niż nawias.

Dość długa, chaotyczna odpowiedź, ale tak, myślę, że opisowy język szablonów ma wielką wartość, a XSLT jest najlepszym i najbardziej znormalizowanym do tej pory.

Największą wadą XSLT jest niezdolność (w jakiejkolwiek rzeczywistej implementacji) do zminimalizowania ilości dokumentu, który musi być przechowywany w pamięci na raz w celu wydajnego przetwarzania. Zamiast tego cały dokument jest wczytywany w jakąś formę reprezentacji DOM i przetwarzanie odbywa się w tym celu. Jeśli dokument jest bardzo duży, to również wymagania dotyczące pamięci. Jednak wiele arkuszy stylów wyraźnie potrzebuje tylko bieżącego znacznika i kilku innych, np. Przodków znacznika, w danym momencie, a zatem może być przetwarzanych przy minimalnej pamięci i wydajnym przesyłaniu strumieniowym.

Tak, jeśli chodzi o język, to dziwne, ale to tylko bariera wejścia. Jeśli znasz XSLT, często jest to łatwiejsze niż alternatywy - ale jeśli będziesz mieć duże dokumenty (lub wiele dokumentów przetwarzanych jednocześnie), wpływ XSLT na pamięć często wymusza inne, bardziej czasochłonne alternatywy.

W rzeczywistości uważam, że bardziej efektywne jest używanie XSL niż innego języka do prezentacji danych. Na przykład możesz przedstawić XML jako plik PDF za pomocą XSL-FO i możesz kontrolować każdy cal, ale jeśli na przykład pracujesz z RDLC (.NET), zobaczysz, że bardzo trudno jest przedstawić dokładnie to, co chcesz.

Nawet ewolucja / korekta jest dość łatwa, ponieważ w XSL każdy element ma swój własny szablon. Myślę, że rozszerzenie XSL jest ważniejsze, jak XSLT i XSL-FO. Dlatego ten język będzie nadal używany w przyszłości (ale mam nadzieję, że będzie on bardziej stabilny i mniej złożony).

Pracuję dla firmy zajmującej się integracją danych i używamy XSLT z naszymi zastrzeżonymi narzędziami jako świetne rozwiązanie obejmujące XML do HTML / XML / Ascii.