Abuzus XML v Javě

ano

Abuzus XML v Javě
« kdy: 13. 02. 2018, 03:06:31 »
Narazil jsem teď na takový zvláštní projekt a nedá mi to tady nenapsat. Jedna firma, která intenzivně pracuje s XML soubory, si udělala vlastní ala-xsd formát, který ji umožňuje volat validační metody v Javě v průběhu validace XML souboru. Tzn. můžou validovat věci i jako je PSČ, oproti databázi. Use case je asi ten, že prostě mají xml s daty, k němu si napíšou to alá-xsd a dají oba sobory jako input do utilitky, která jim to ovaliduje. Příjde mi to nicméně takové podivné:

1. K čemu je samotná validace xml bez následného načtení xml např kvůli vložení do db? V tom připadě, standardní způsob je si prostě udělat modelové třídy xml souboru, obohatit to třeba o Hibernate Validator (přes anotace vč. custom validací). Tzn. tady v tomto use case já můžu jednoznačně validovat až na straně javy a nepotřebuju takový zbytečný alá-xsd formát, protože stejně potřebuju mít modelové třídy.

2. Řekněme, že z nějakého úchylného důvodu ja budu chtít XML opravdu jen validovat a dál s jeho obsahem nijak nepracovat. V tom případě opět nechápu, proč se trápit s takovýmto alá-xsd frameworkem - vždyť místo alá-xsd si k tomu xmlku napíšu obyčejné POJO třídy, opět si tam dám standardní Hibernate Validator anotace, a jako input do té utilitky si dám prostě to xmlko a to POJO. Bude to 100x lepší, než se štvát s nějakým takovým zbytečným frameworkem, protože budu mít statickou typovou kontrolu a podle mě to bude v Javě i pěknější.

Co mi příjde zvláštní, ta firma to má očividně jako svůj produkt a asi se to snaží prodávat. Musím říct že teď, po tom, co jsem viděl, se mi k nim moc nechce. Navíc to, co oni vytvořili, přesně umí Saxon Processor, který je placený, pomocí XSD 1.1 assertion dokáže zavolat javovskou metodu z classpath.

Podle mě by se teda takovéto věci neměly dít, přecejen člověk by se měl nejprve trochu zamyslet, než něco začne takového vyrábět :/


Ivan Nový

Re:Abuzus XML v Javě
« Odpověď #1 kdy: 13. 02. 2018, 05:46:33 »
No z nějakého důvodu lidskému mozku vyhovujespíše jazyková homogenita, proto programátoři časem inklinují k protežování jednoho jazyka na úkor jiných. Vy protežujete Javu, protože s ní nejčastěji pracujete, oni prostředky xml. V dobách největší slávy xml to vypadalo, že vznikne programovací jazyk, který bude mít formu xml. Jde o typické míchání deklarativního a procedurálního programování. Například:
Kód: [Vybrat]
<if cond="$z=1">
    <for item="$x" range="10">
          <let item="$y" value="$x" />
    </for>
</if>

Re:Abuzus XML v Javě
« Odpověď #2 kdy: 13. 02. 2018, 06:18:40 »
Xsd je poměrně slabé na validaci dat, tak jednoduše hledají způsob, jak ho vylepšit.

S xml se dá udělat opravdu hodně dalších věcí, než jej uložit do SQL databáze přes hibernate, takže hibernate by zde byl zbytečná a možná i nedostatečná depedence. Navíc by se musel udělat nejspíš poměrně kompletní model daného xml, zatímco přes ten jejich nástroj (předpokládám) definují jenom handlery přes třeba xpath.

Poslední věc je, že validace není nejspíš vázána na konkrétní jazyk, takže se dá implementovat v kterémkoli jazyku a úrovní.

Kdysi jsem psal (komplexnější) framework, který validátor definoval přes anotace, ale exportoval je do klienta běžícího v browseru. Tam se jakýkoliv uživatelský vstup validoval ještě před posláním na server, znovu na základě stejných anotací na backendu.

Kromě lepší user experience je hlavně takový přístup bezpečnější, než si validace psát třeba v controlleru a hlavně je konzistentně udržovat.

Re:Abuzus XML v Javě
« Odpověď #3 kdy: 13. 02. 2018, 07:10:10 »
Vy z nějakého důvodu předpokládáte, že se s tím XML bude pracovat jedině přes objekty v Javě. Přitom jste sám napsal o vložení XML do databáze, a k tomu opravdu žádnou Javu nepotřebujete. S XML můžete pracovat pomocí XSLT, XQuery, XProc, můžete ho uložit do XML databáze, i v té Javě s ním můžete pracovat pomocí DOMu.

Mně zase připadá zvrácené, když se data z relační databáze mapují na pracně vytvářené Java beany, aby se vzápětí serializovaly přes nějaký šablonovací systém do HTML. Přitom výsledek dotazu do relační databáze se dá snadno serializovat do XML (některé databáze pro to mají přímo vestavěnou podporu), a to se dá pomocí XSLT transformovat rovnou do HTML.

Tondulin

Re:Abuzus XML v Javě
« Odpověď #4 kdy: 13. 02. 2018, 09:39:02 »
Pokud je nedostačující XSD, např. kvůli komplikovanějším integritním omezením, lze použít Schematron nebo RelaxNG. U druhého zmiňovaného je celkem šikovná kompaktní syntaxe, která je pro člověka (bez použití specializovaných programů jako XMLSpy aj.) mnohem více čitelnější.

Používat vlastní validátor nedoporučuju, jsem si téměř jistý, že správně zvaliduje i to, co nemá.


Youda

Re:Abuzus XML v Javě
« Odpověď #5 kdy: 13. 02. 2018, 09:46:02 »
Vy z nějakého důvodu předpokládáte, že se s tím XML bude pracovat jedině přes objekty v Javě. Přitom jste sám napsal o vložení XML do databáze, a k tomu opravdu žádnou Javu nepotřebujete. S XML můžete pracovat pomocí XSLT, XQuery, XProc, můžete ho uložit do XML databáze, i v té Javě s ním můžete pracovat pomocí DOMu.

Mně zase připadá zvrácené, když se data z relační databáze mapují na pracně vytvářené Java beany, aby se vzápětí serializovaly přes nějaký šablonovací systém do HTML. Přitom výsledek dotazu do relační databáze se dá snadno serializovat do XML (některé databáze pro to mají přímo vestavěnou podporu), a to se dá pomocí XSLT transformovat rovnou do HTML.

Opravdu netusim, co je tak pracneho na naplneni beanu z radku resultsetu. Samotna XSLT transformace je narocnejsi task.
Kdysi jsem napsal jednu utilitku, ktera poslala XMLTREE z Oraclu primo do browseru a tam se provadela XSLT transformace, bylo to brutalne pomale, zvlast na internet exploiteru, tabulka a 1500 radky se z XMLTREE generovala 10 sekund.
Tak jsem XSLT transformaci presunul na uroven Tomcatu, pak byla rychlost slusna, lec zatez Tomcatu znatelne vyssi, nez hloupe JSP stranky se zakladnimi <c:> tagy.

A dneska je XSLT uplna blbost, v dobe JSF2 knihoven typu Primefaces.

Youda

Re:Abuzus XML v Javě
« Odpověď #6 kdy: 13. 02. 2018, 09:52:56 »
Xsd je poměrně slabé na validaci dat, tak jednoduše hledají způsob, jak ho vylepšit.

S xml se dá udělat opravdu hodně dalších věcí, než jej uložit do SQL databáze přes hibernate, takže hibernate by zde byl zbytečná a možná i nedostatečná depedence. Navíc by se musel udělat nejspíš poměrně kompletní model daného xml, zatímco přes ten jejich nástroj (předpokládám) definují jenom handlery přes třeba xpath.

Poslední věc je, že validace není nejspíš vázána na konkrétní jazyk, takže se dá implementovat v kterémkoli jazyku a úrovní.

Kdysi jsem psal (komplexnější) framework, který validátor definoval přes anotace, ale exportoval je do klienta běžícího v browseru. Tam se jakýkoliv uživatelský vstup validoval ještě před posláním na server, znovu na základě stejných anotací na backendu.

Kromě lepší user experience je hlavně takový přístup bezpečnější, než si validace psát třeba v controlleru a hlavně je konzistentně udržovat.

A dneska to resej knihovny

Custom client side validace v Primefaces:
https://www.primefaces.org/showcase/ui/csv/custom.xhtml

Tohle je nejslozitejsi varianta, vlevo je odkaz "Client Side Validation" s jednodussimi typy validaci typu prosty regex, tam staci prakticky zadat jenom onen regex a hotovo.

Re:Abuzus XML v Javě
« Odpověď #7 kdy: 13. 02. 2018, 21:04:43 »
1. K čemu je samotná validace xml bez následného načtení xml např kvůli vložení do db? V tom připadě, standardní způsob je si prostě udělat modelové třídy xml souboru, obohatit to třeba o Hibernate Validator (přes anotace vč. custom validací). Tzn. tady v tomto use case já můžu jednoznačně validovat až na straně javy a nepotřebuju takový zbytečný alá-xsd formát, protože stejně potřebuju mít modelové třídy.

Samotná validace je očividně k tomu, aby bylo to xml podle určitých kritérií validní. Bez návaznosti na zbytek to nelze nijak odsoudit.

2. Řekněme, že z nějakého úchylného důvodu ja budu chtít XML opravdu jen validovat a dál s jeho obsahem nijak nepracovat. V tom případě opět nechápu, proč se trápit s takovýmto alá-xsd frameworkem - vždyť místo alá-xsd si k tomu xmlku napíšu obyčejné POJO třídy, opět si tam dám standardní Hibernate Validator anotace, a jako input do té utilitky si dám prostě to xmlko a to POJO. Bude to 100x lepší, než se štvát s nějakým takovým zbytečným frameworkem, protože budu mít statickou typovou kontrolu a podle mě to bude v Javě i pěknější.

Co mi příjde zvláštní, ta firma to má očividně jako svůj produkt a asi se to snaží prodávat. Musím říct že teď, po tom, co jsem viděl, se mi k nim moc nechce. Navíc to, co oni vytvořili, přesně umí Saxon Processor, který je placený, pomocí XSD 1.1 assertion dokáže zavolat javovskou metodu z classpath.

Volat javovskou třídu z xslt umí kde kdo - saxon, xalan... Ideální je postavit tu validaci na těchto nástrojích. Opět, nic špatného na tom v principu nevidím - pokud jde o primární formát pro výměnu nebo ukládání dat, je jedině dobře, že to validují. Zvrhlé by naopak bylo to xml mít nevalidované - což je bohužel taky dost častý případ.

Jinak pochybuju, že by tím produktem byl jen nástroj na validaci, nejspíš kolem toho bude nějaký ekosystém, který může dávat jako celek smysl. Řada organizací potřebuje držet kontinuitu po mnoho let, takže nějaký formát s dobrou specifikací a ověřenou implementací - či rovnou s více nezávislými implementacemi - je ideální.

Re:Abuzus XML v Javě
« Odpověď #8 kdy: 13. 02. 2018, 22:44:25 »
Opravdu netusim, co je tak pracneho na naplneni beanu z radku resultsetu.
Já netuším, kde jste sebral, že je to pracné. Já jsem psal, že je pracně vytvářená Java beana – i když jí budete vytvářet a udržovat synchronní s databázovým schématem nějakým automatickým nástrojem, pořád je údržba té beany pracnější, než žádná beana.

Samotna XSLT transformace je narocnejsi task.
Naprogramovat je to stejně snadné, jako to naplnění beanu z resultsetu, za běhu to také není nijak náročné.

zatez Tomcatu znatelne vyssi, nez hloupe JSP stranky se zakladnimi <c:> tagy.
JSP se kompiluje do Java bytekódu. Placené verze Saxonu umí kompilovat i XSLT.

A dneska je XSLT uplna blbost, v dobe JSF2 knihoven typu Primefaces.
Spíš to vypadá, že nevíte, co je XSLT. Když potřebuju jenom data zobrazit podle svého, nepotřebuju tam tahat JSF – zvlášť když to chci zobrazit třeba jako PDF, u čehož mi JSF nepomůže vůbec nijak.

Youda

Re:Abuzus XML v Javě
« Odpověď #9 kdy: 14. 02. 2018, 10:24:51 »
Já netuším, kde jste sebral, že je to pracné. Já jsem psal, že je pracně vytvářená Java beana – i když jí budete vytvářet a udržovat synchronní s databázovým schématem nějakým automatickým nástrojem, pořád je údržba té beany pracnější, než žádná beana.
Heh, muzu vedet, co je tak sloziteho, kdyz do Entity beanu pridam :
@Column
private int newColumn;

a pak kliknout na generate getters and setters?
Vedlejsim efektem je zakladni inheritni kontrola, pokud v resultsetu nebude "newcolumn" ulozitelny do int - exception. XSLT? XPATH proste nic nenasel, do vysledneho HTML se vypise prazdny retezec.

To mi prijde krapet jednodussi, nez pridat dalsi XPATH radek to XSLT template.

Naprogramovat je to stejně snadné, jako to naplnění beanu z resultsetu, za běhu to také není nijak náročné.
Ne, neni. Testovano osobne.

JSP se kompiluje do Java bytekódu. Placené verze Saxonu umí kompilovat i XSLT.
Ehm,  XSLT engine javax.xml.transform.* se taktez kompiluje do bytecode. S vysledkem brutalne pomalejsim nez Beany a JSP tagy.,

Spíš to vypadá, že nevíte, co je XSLT. Když potřebuju jenom data zobrazit podle svého, nepotřebuju tam tahat JSF – zvlášť když to chci zobrazit třeba jako PDF, u čehož mi JSF nepomůže vůbec nijak.
Ehm, mluvime tady jaksi v urcitem kontextu.
A v kontextu webu, kde dneska vladne Javascript (a AJAX Primefaces je jenom priklad, klidne mozno dosadit REACT) znamena, ze XSLT transformace pro WEB je k nicemu.

Re:Abuzus XML v Javě
« Odpověď #10 kdy: 14. 02. 2018, 11:34:11 »
Ehm, mluvime tady jaksi v urcitem kontextu.
A v kontextu webu, kde dneska vladne Javascript (a AJAX Primefaces je jenom priklad, klidne mozno dosadit REACT) znamena, ze XSLT transformace pro WEB je k nicemu.

To je otázka, zda zde jde o kontext webu. Dost pravděpodobně ne - alespoň ne u původního dotazu. Takže ten  spor dost postrádá smysl. Prostě je tu víc nástrojů a každý se hodí pro něco jiného. Apriori zatracovat xslt bez znalosti kontextu mi přijde jako holý nesmysl.

Re:Abuzus XML v Javě
« Odpověď #11 kdy: 14. 02. 2018, 13:56:45 »
Heh, muzu vedet, co je tak sloziteho, kdyz do Entity beanu pridam :
Přidávat něco do neexistujícího entity beanu je podle mne docela obtížné. Docela by mne zajímalo, jak to děláte. Ale spíš si myslím, že jste pořád ještě nepochopil, že celý ten váš entity bean je zbytečný a já se bez něj obejdu.

Ne, neni. Testovano osobne.
To, že vy něco neumíte, neznamená, že to nejde.

Kód: [Vybrat]
Source xslt = new StreamSource(new File("template.xsl"));
Source input = new StreamSource(new File("input.xml"));
Result output = new StreamResult(new File("output.xml"));
Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt);
transformer.transform(xml, output);

Co je na tom složité?

Ehm, mluvime tady jaksi v urcitem kontextu.
A v kontextu webu, kde dneska vladne Javascript (a AJAX Primefaces je jenom priklad, klidne mozno dosadit REACT) znamena, ze XSLT transformace pro WEB je k nicemu.
To, že se někde používá AJAX, neznamená, že musí být všude. Pokud potřebuju vygenerovat nějaký report z relační databáze, je výstup z databáze do XML a následná XSLT transformace do HTML5 to nejjednodušší, co můžu použít, a nemusím to komplikovat AJAXem a RESTem a frameworky na tohle a na tamto. Výsledná stránka bude krásně jednoduchá, nebude potřebovat žádný JavaScript a upravit jí bude znamenat oeditovat jeden soubor na serveru.