XSLT - Java

[Xoverride]

Stel je navigeert naar een url test.do. Deze url staat gemapt naar een controller die netjes al je spulletje bij elkaar harkt. Je hebt dan wat gevulde domeinobjecten die je naar de view wil doorzetten.

Normaliter met bijvoorbeeld Spring zou je deze domeinobjecten op je model zetten en op je jsp met JSTL uitlezen.

Hoe kan je dit het beste doen als je gebruik wil maken van XSLT? Ik gebruik Spring voor de wiring van url tot view ( http://static.springframe...rence/view.html#view-xslt ) . Maar goed naast Spring: is het mogelijk om vanuit XSLT te praten met je opgeleverde bij elkaar geharkte domeinobjecten als je van je controller naar je XSLT template gaat?

XSLT wordt bij het bedrijf gebruikt omdat het als erg prettig wordt ervaren. Aan mij de eervolle taak een oplossing te zoeken voor het praten tussen objecten en xslt.

enig idee, iemand?

[Marcj]

Ik begrijp niet helemaal wat je nu wilt. XSLT is bedoelt met XML document te transformeren naar een ander XML document (bijvoorbeeld XHTML). XSLT is dus niet bedoelt om direct objecten om te zetten naar XML, dat is niet mogelijk.

Ik denk dus dat jouw views XML genereren en dat je deze wilt transformeren naar bijvoorbeeld XHTML?

[Xoverride]

Marcj schreef op zondag 17 augustus 2008 @ 19:51:
Ik begrijp niet helemaal wat je nu wilt. XSLT is bedoelt met XML document te transformeren naar een ander XML document (bijvoorbeeld XHTML). XSLT is dus niet bedoelt om direct objecten om te zetten naar XML, dat is niet mogelijk.

Ik denk dus dat jouw views XML genereren en dat je deze wilt transformeren naar bijvoorbeeld XHTML?

Ik weet niet of je bekend bent met Spring MVC, maar het is dus zo dat ik op een gegeven moment voordat ik de user presenteer met een pagina een boom met objecten heb.

Bijvoorbeeld een List vol met artikelen. De class Article is dan een domeinobject en de List bevat dus een aantal gevulde objecten van het type Article.

Het punt is dus dat dit bedrijf waar ik zit heel erg gespecialiseerd is in werken met XSLT voor het uiteindelijk maken van de HTML. De vraag is dus: hoe kan ik nu mijn List met gevulde objecten(Article) uitlezen in XSLT.

Zoals ik zelf al aangaf in de OP heb ik dus nu zelf de hele List met Articles naar XML getransformeerd en deze uitgelezen met XSLT. Ik neem aan dat er een betere manier is, of dat je dit nooit zou moeten doen. Als dat laatste het geval is, zou dat betekenen dat je in principe alleen maar op een goede manier met XSLT kan werken als XML je bron is. In dit geval zijn domeinobjecten mijn bron, dus now what?

[Marcj]

Xoverride schreef op maandag 18 augustus 2008 @ 09:00:
[...]
Zoals ik zelf al aangaf in de OP heb ik dus nu zelf de hele List met Articles naar XML getransformeerd en deze uitgelezen met XSLT. Ik neem aan dat er een betere manier is, of dat je dit nooit zou moeten doen. Als dat laatste het geval is, zou dat betekenen dat je in principe alleen maar op een goede manier met XSLT kan werken als XML je bron is. In dit geval zijn domeinobjecten mijn bron, dus now what?

Dit kan zo prima, er is geen andere manier om XSLT te gebruiken. Ik heb het zelf ook wel eens op deze manier gedaan, omdat ik ook de rauwe XML soms wil terug geven (voor specifieke clients).

Om domeinobject in XSLT te gebruiken zul je deze ook eerst zelf moeten omzetten naar een eigen XML formaat. Deze kan je dan weer uitlezen met XSLT. XSLT kan geen objecten gebruiken direct gebruiken.

Als je dit per se wel zou willen (beetje misbruik van het idee, maar goed), dan zou je een XMLEventReader kunnen implementeren die jouw specifieke objecten leest en hiervan XMLEvents genereerd. Ik zou echter gewoon eerst een XML creëeren (eventueel via een DOM oid) en deze aan de XSLT tranformer geven.

Wat je trouwens ook kan doen is de rauwe XML aan de client geven en hierin het XSL document opgeven als 'stylesheet'. De meeste browser kunnen daar tegenwoordig prima mee overweg.

[Xoverride]

Marcj schreef op maandag 18 augustus 2008 @ 09:21:
[...]

Dit kan zo prima, er is geen andere manier om XSLT te gebruiken. Ik heb het zelf ook wel eens op deze manier gedaan, omdat ik ook de rauwe XML soms wil terug geven (voor specifieke clients).

Om domeinobject in XSLT te gebruiken zul je deze ook eerst zelf moeten omzetten naar een eigen XML formaat. Deze kan je dan weer uitlezen met XSLT. XSLT kan geen objecten gebruiken direct gebruiken.

Als je dit per se wel zou willen (beetje misbruik van het idee, maar goed), dan zou je een XMLEventReader kunnen implementeren die jouw specifieke objecten leest en hiervan XMLEvents genereerd. Ik zou echter gewoon eerst een XML creëeren (eventueel via een DOM oid) en deze aan de XSLT tranformer geven.

Wat je trouwens ook kan doen is de rauwe XML aan de client geven en hierin het XSL document opgeven als 'stylesheet'. De meeste browser kunnen daar tegenwoordig prima mee overweg.

Het punt is: het lijkt een beetje dubbel om mijn domeinobjecten eerst te transformeren naar XML. Normaliter zou ik deze gewoon direct op de jsp uitlezen met JSTL die dus de getters van een object aanroept.

Er wordt nu met .NET een XpathNavigator teruggestuurd. Een soort navigator op het object dus eigenlijk. Het is meer een soort pointer naar een object waardoor je met xpath in xslt je objecten kan uitlezen. Zoiets zoek ik dus ook, maar dan voor Java. Die XMLEventReader doet dit volgens mij niet zo.

[Vaudtje]

XSLT is transformatie op basis van een XML document.
Als je op basis van een Java objectstructuur een transformatie met XSLT wil laten plaats vinden, zul je die objecten eerst moeten serialiseren naar een XML DOM.

Ik vermoed dat reden dat dat in .NET vanzelf lijkt te gaan, gelegen is in het feit dat in .NET elk object automatisch een XML serialisatie ingebouwd heeft (elk object heeft een toXML() die vanzelf werkt, je hoeft hem niet zelf te implementeren).
De serialisatie vindt waarschijnlijk transparant plaats in de XpathNavigator die je noemt, maar is dus ook in .NET aanwezig om van objectmodel naar XML DOM te komen.

In Java moet je helaas de serialisatie naar XML zelf regelen (al zijn er wel libraries die je daarbij helpen, zoals Castor).

[ Voor 14% gewijzigd door Vaudtje op 18-08-2008 12:51 ]

[Xoverride]

Vaudtje schreef op maandag 18 augustus 2008 @ 10:08:
XSLT is transformatie op basis van een XML document.
Als je op basis van een Java objectstructuur een transformatie met XSLT wil laten plaats vinden, zul je die objecten eerst moeten serialiseren naar een XML DOM.

Ik vermoed dat reden dat dat in .NET vanzelf lijkt te gaan, gelegen is in het feit dat in .NET elk object automatisch een XML serialisatie ingebouwd heeft (elk object heeft een toXML() die vanzelf werkt, je hoeft hem niet zelf te implementeren).
De serialisatie vindt waarchijnlijk transparant plaats in de XpathNavigator die je noemt, maar is dus ook in .NET aanwezig om van objectmodel naar XML DOM te komen.

In Java moet je helaas de serialisatie naar XML zelf regelen (al zijn er wel libraries die je daarbij helpen, zoals Castor).

Juist ,dat is precies mijn vermoeden. Dit brengt mij weer een stapje verder. Kijk een object een toXML functie geven is een fluitje van een cent. Ik gebruik nu Xtream om al mijn objecten in 1 keer naar XML te transformeren voor een bepaalde view. Ik hoorde dat .Net als het ware on the fly xml genereert als je bijvoorbeeld een getter van een object wil aanspreken. Dus niet in 1 keer een serialisatie maar beetje bij beetje.

Als dit inderdaad zo werkt, dan is dat opzich ook wel tricky, omdat de boel ook on the fly can crashen.

[Janoz]

Misschien is het handig wanneer je verteld wat er wordt gebruikt voor de xslt. Dus door welke software worden de uit je java applicatie opgeleverde xml bestanden getransformeerd?

[Xoverride]

Janoz schreef op maandag 18 augustus 2008 @ 11:35:
Misschien is het handig wanneer je verteld wat er wordt gebruikt voor de xslt. Dus door welke software worden de uit je java applicatie opgeleverde xml bestanden getransformeerd?

De XSLT transformeerd de xml naar een mooie view. Met Xtream genereer ik van java objecten xml.

Of bedoel je dat niet?

[Janoz]

Nee, dat bedoel ik niet. Ik weet wat XSLT is. Het punt is dat XSLT een bestand is. Net zoals je een .DOC bestand met word opent is er ook een stuk software die je XML en een XSLT neemt om vervolgens een andere XML uit te spugen. Je gebruikt Xtream om XML te genereren, maar wat gebruik je om van die XML met je XSLT bestand een andere X(HT)ML te genereren.

[Vaudtje]

Een equivalent van .NET's XPathNavigator lijkt mij overigens JXPath.
Maar die heb je dus alleen nodig als je zelf de XSLT engine bouwt in Java lijkt me (wat Janoz dus vraagt).

[Xoverride]

Janoz schreef op maandag 18 augustus 2008 @ 11:45:
Nee, dat bedoel ik niet. Ik weet wat XSLT is. Het punt is dat XSLT een bestand is. Net zoals je een .DOC bestand met word opent is er ook een stuk software die je XML en een XSLT neemt om vervolgens een andere XML uit te spugen. Je gebruikt Xtream om XML te genereren, maar wat gebruik je om van die XML met je XSLT bestand een andere X(HT)ML te genereren.

De uiteindelijke HTML wordt door een zelfgemaakt tooltje in .NET naar HTML geschreven.

Ik weet niet of JXpath is wat ik bedoel. Met JXpath kan je niet vanuit je xslt template je object benaderen, of wel? Oftewel volgens mij kan je daarmee niet je opgeleverde domeinobjecten mee uitlezen zoals met jstl, of zie ik dat verkeerd? Je zal toch een serialisatie van je objecten naar xml moeten doen wil je ze kunnen uitlezen in xslt, toch

[Vaudtje]

Een zelfgemaakt .NET tooltje zal niet rechtstreeks het Java objectmodel aan kunnen spreken.
Ik neem dus aan dat 'het tooltje' gewoon XML consumeert.
Die moet je dan dus maken zoals je dat al doet met XStream.

Als je naar de client browser XML zou willen renderen (of als 'het tooltje' HTTP requests doet namens de client), zou je misschien in je .JSP een xml doctype kunnen declareren, en dus in je .JSP de xml opbouwen?

[ Voor 6% gewijzigd door Vaudtje op 18-08-2008 13:32 ]

[Xoverride]

Nou het .NET verhaal staat wel los van dit alles. Ik ben een Java omgeving aan het opzetten en zodoende moet ik dus kijken naar hoe bepaalde dingen nu opgelost zijn in de huidige .Net omgeving.

Weet je hoe je vanuit Spring MVC domeinobjecten op je model kan zetten en deze op je view uitlezen? Dat is eigenlijk wat ik zoek, maar dan voor XSLT. Nu gooi ik eigenlijk een complete XML boom naar mijn XSLT "view"

[Vaudtje]

Zonder de architectuur van je Java app te kennen is het volkomen onduidelijk wat je bedoelt met "domeinobjecten op je model zetten" of "XSLT view".
Wat is de XSLT engine die je gebruikt? Draait die in dezelfde VM als je Spring app?

Het lijkt er op dat je vraag eigenlijk is: Hoe render ik mijn objectmodel eenvoudiger naar XML?
Daarop is het antwoord: dat gaat niet eenvoudiger dan met XStream.

[MSalters]

Xoverride schreef op maandag 18 augustus 2008 @ 09:00:
Het punt is dus dat dit bedrijf waar ik zit heel erg gespecialiseerd is in werken met XSLT voor het uiteindelijk maken van de HTML. De vraag is dus: hoe kan ik nu mijn List met gevulde objecten(Article) uitlezen in XSLT.

Het bedrijf waar ik zit is heel erg gespecialiseerd in hamers. De vraag is dus: hoe gebruik ik een hamer om mijn schroef in de muur te slaan?

Sorry, maar XSLT is een middel, geen doel.

[Vaudtje]

_{@MSalters:
Ik hoop dat je niet alleen maar probeert te trollen, maar dat je bedoelt:
"Waarom uberhaupt die tussenstap naar XML als je toch in HTML wil renderen?"
In dit geval kan dat bijvoorbeeld zijn omdat ze met dezelfde XSLT's zowel .NET als Java output willen renderen.
(Ik ken zelf ook Java webapps die via XML/XSLT HTML renderen, dus helemaal van de pot gerukt is het blijkbaar niet)
Hoewel het vaker voorkomt dat een TS in zijn vraagstelling een foute aanname maakt, lijkt me deze topicstart daar niet echt aanleiding voor geven, zeker gezien het feit dat de posts al een tijdje ergens anders over gaan.}

[Xoverride]

MSalters schreef op maandag 18 augustus 2008 @ 14:58:
[...]

Het bedrijf waar ik zit is heel erg gespecialiseerd in hamers. De vraag is dus: hoe gebruik ik een hamer om mijn schroef in de muur te slaan?

Sorry, maar XSLT is een middel, geen doel.

Ik moest lachen

[Xoverride]

Vaudtje schreef op maandag 18 augustus 2008 @ 14:53:
Zonder de architectuur van je Java app te kennen is het volkomen onduidelijk wat je bedoelt met "domeinobjecten op je model zetten" of "XSLT view".
Wat is de XSLT engine die je gebruikt? Draait die in dezelfde VM als je Spring app?

Het lijkt er op dat je vraag eigenlijk is: Hoe render ik mijn objectmodel eenvoudiger naar XML?
Daarop is het antwoord: dat gaat niet eenvoudiger dan met XStream.

Ok helder. Het is meer dat ik een vergelijking probeer te trekken met .NET. In Java heb ik het nu zo geregeld dat ik objecten die ik op de front-end aan de user wil presenteren omvorm naar XML met Xstream.

In .Net kan je objecten Xpathnavigable maken en op die manier kan je met Xpath als het ware over je object heen gaan: het domeinobject Article met bijvoorbeeld een property writer kan je dan benanderen in je xslt template met article/writer.

Zoals het dus lijkt hoef je in .Net niet je object naar XML te transformeren. In Java doe ik dat dus nu wel. Ik vroeg mij af of er niet net zoiets was voor Java als dat je dat bij .Net doet. Maar zoals uit de posts hierboven blijkt kennelijk niet.

[Janoz]

Dat is er wel in Java, maar dan moet je je zelfgeschreven .NET tootlje die enkel XML input accepteerd overboord gooien en het hele xslt gebeuren ook in java gaan doen. Dan kun je het java equivalent van Xpathnavigable gebruiken (Welke dit is weet ik zo niet uit mijn hoofd, maar dat zou best JXpath kunnen zijn). De enige reden waarom dat nu niet lukt is omdat het domein in 'java space' bestaat terwijl de transformatie in '.NET space' gebeurt.

[Xoverride]

Janoz schreef op maandag 18 augustus 2008 @ 22:58:
Dat is er wel in Java, maar dan moet je je zelfgeschreven .NET tootlje die enkel XML input accepteerd overboord gooien en het hele xslt gebeuren ook in java gaan doen. Dan kun je het java equivalent van Xpathnavigable gebruiken (Welke dit is weet ik zo niet uit mijn hoofd, maar dat zou best JXpath kunnen zijn). De enige reden waarom dat nu niet lukt is omdat het domein in 'java space' bestaat terwijl de transformatie in '.NET space' gebeurt.

Nee nee, de werelden zijn apart van elkaar. Java en .Net gaan niet samen werken. Ik kijk slechts puur naar wat er nu aan de .Net kant is gemaakt. Dat zelfgemaakte tooltje in .Net gaan we dus aan de Java kant sowieso niet gebruiken.

Het java equivalent van Xpathnavigable is dus het probleem, daar ben ik naar op zoek. Ik heb naar Jxpath gekeken maar volgens mij doet dat niet wat ik wil, namelijk objecten doorzetten naar mijn xslt templates en daar uitlezen zonder eerst volledig om te zetten naar XML.

[Janoz]

Dus na 20 postings komt daadwerkelijk de echte onderliggende vraag naar boven:

"Wat is een goede java equivalent van Xpath navigable?"

[Xoverride]

Janoz schreef op dinsdag 19 augustus 2008 @ 09:05:
Dus na 20 postings komt daadwerkelijk de echte onderliggende vraag naar boven:

"Wat is een goede java equivalent van Xpath navigable?"

Er van uitgaande dat dat de beste oplossing is wel ja. In de OP is het redelijk open gelaten wat de beste oplossing kan zijn. Als dat een equivalent is van Xpath navigable, dan word dat nu de vraag.

Het is dan ook niet echt allerdaags materiaal dit.

[Vaudtje]

Maar als je in code je objectmodel benadert via XPath expressies, vind ik het een nogal vreemd om dat XSLT te noemen, of is dat toch niet wat er gebeurt?

[ Voor 19% gewijzigd door Vaudtje op 19-08-2008 09:57 ]

[Xoverride]

Vaudtje schreef op dinsdag 19 augustus 2008 @ 09:54:
Maar als je in code je objectmodel benadert via XPath expressies, vind ik het een nogal vreemd om dat XSLT te noemen, of is dat toch niet wat er gebeurt?

Dit onderste stukje code maakt wellicht eea duidelijk. Zoals je ziet gebruik ik Spring om in mijn controller uit te komen. Ik haal een blog op en wil die doorzetten naar de view. Dit zou ik eigenlijk willen kunnen:

<xsl:template match="/blog/writer/"> writer is bijvoorbeeld een attribuut van blog.

code:

package bla.web.mvc.controllers;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.AbstractController;

import dushi.web.mvc.domain.Blog;
import dushi.web.mvc.service.BlogInterface;

public class ViewBlogController extends AbstractController{
    
    private BlogInterface blogInterface;

    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {

               ModelAndView mav = new ModelAndView("viewblogpage");
        

        Blog blog = blogInterface.getTestBlog();
                mav.addobject("blog" , blog);
        
        
                
                
        return mav;

    }
    
    public void setBlogInterface(BlogInterface blogInterface) {
        this.blogInterface = blogInterface;
    }

}

[Janoz]

@vaudtje
Waarschijnlijk gebruikt de XSLT parser XPath om zijn input in te lezen. Bij een Xpath navigable object model is er dan geen tussenliggende xml nodig. Het objectmodel manifesteert zich als een DOM dat rechtstreeks uitgelezen kan worden.

[matthijsln]

Ik moet zeggen dat ik de vraag van de TS helemaal niet vreemd vindt, volgens mij is ie gewoon op zoek naar het volgende stukje documentatie: http://static.springframe...rence/view.html#view-xslt

Hij gebruikt al XStream dus hoeft hij alleen maar een org.springframework.web.servlet.view.xslt.AbstractXsltView te implementeren die in de createXsltSource() methode een Source maakt dmv XStream.

edit: ik zie dat in de topic start de doc link ook al staat maar de vraag "is het mogelijk om vanuit XSLT te praten met je opgeleverde bij elkaar geharkte domeinobjecten als je van je controller naar je XSLT template gaat?" ja, dat is dus de hele bedoeling, door je domeinobjecten naar XML te marshallen wat je moet doen dmv het implementeren van een AbstractXsltView.

[ Voor 30% gewijzigd door matthijsln op 19-08-2008 10:41 ]

[Janoz]

Het punt is dat je nog steeds een kopie van je domein maakt naar een DOM. Het zou mooi zijn wanneer je een interface op je domein kunt zetten zodat het zich voordoet als een DOM. Dat is wat Xpath navigable doet (vermoed ik). Je vuurt een XPath query af op je domein en daar zit een stuk code die net doet of het naar XML omgezet is en vervolgens kijkt welke property van welk object dan terug gegeven zou worden.

[matthijsln]

Janoz schreef op dinsdag 19 augustus 2008 @ 10:45:
Het punt is dat je nog steeds een kopie van je domein maakt naar een DOM. Het zou mooi zijn wanneer je een interface op je domein kunt zetten zodat het zich voordoet als een DOM. Dat is wat Xpath navigable doet (vermoed ik). Je vuurt een XPath query af op je domein en daar zit een stuk code die net doet of het naar XML omgezet is en vervolgens kijkt welke property van welk object dan terug gegeven zou worden.

Ik snap het punt niet zo. Je java objecten moeten toch naar een DOM worden omgezet worden voordat het bruikbaar is in XSLT.

Nu gebruikt de TS al XStream waarmee dat kan. "objecten doorzetten naar mijn xslt templates en daar uitlezen zonder eerst volledig om te zetten naar XML.". Waarom is het een probleem dat dit eerst volledig gebeurt? Het enige wat ik me kan voorstellen is eventueel performance en het te ver doorlopen van de object tree. De oplossingen daarvoor zijn of specificeren tot hoever de object tree moet worden gedomificeerd, of zoals .NET een "lazy" iets wat alleen objecten omzet naar DOM wanneer ze worden gerefereeerd.

Voor wat betreft het laatste vraag ik het me af of het met de XSLT parsers icm je XSLT stylesheets in Java zinnig is. Ik denk dat bij de meeste transformaties toch wel de hele source XML tree wordt doorlopen.

[Janoz]

matthijsln schreef op dinsdag 19 augustus 2008 @ 10:55:
Ik snap het punt niet zo. Je java objecten moeten toch naar een DOM worden omgezet worden voordat het bruikbaar is in XSLT.

Dat hoeft niet. Door een DOM interface (achtig iets) op je objecten te zetten kun je het uitvragen alsof het een DOM is. Er is dan geen tussenliggende kopie nodig. . Dat scheelt een heleboel geheugen gebruik. Zolang de interface efficient geimplementeerd is kost het daarnaast ook geen performance tov de xml oplossing (werkt zelfs efficienter omdat je de conversie stap van al je objecten overslaat)

[Xoverride]

Janoz schreef op dinsdag 19 augustus 2008 @ 11:06:
[...]

Dat hoeft niet. Door een DOM interface (achtig iets) op je objecten te zetten kun je het uitvragen alsof het een DOM is. Er is dan geen tussenliggende kopie nodig. . Dat scheelt een heleboel geheugen gebruik. Zolang de interface efficient geimplementeerd is kost het daarnaast ook geen performance tov de xml oplossing (werkt zelfs efficienter omdat je de conversie stap van al je objecten overslaat)

Spijker of de kop. Dat is exact wat ik bedoel. Het linkje dat is genoemd had ik inderdaad al gevonden en ben daarmee aan de slag gegaan.

Hetgeen Janoz schrijft is precies wat ik bedoel en naar op zoek ben. Vooralsnog kan ik niet iets vinden dat lijkt op het Xpath navigable van .Net voor Java.

[matthijsln]

Xoverride schreef op dinsdag 19 augustus 2008 @ 11:28:
[...]
Spijker of de kop. Dat is exact wat ik bedoel. Het linkje dat is genoemd had ik inderdaad al gevonden en ben daarmee aan de slag gegaan.

Hetgeen Janoz schrijft is precies wat ik bedoel en naar op zoek ben. Vooralsnog kan ik niet iets vinden dat lijkt op het Xpath navigable van .Net voor Java.

Maar is dit nu al nodig? Klinkt een beetje als premature optimization. Probeer eerst gewoon de simpele volledige domificatie van je model en maak je applicatie af. Als je dan nog performance problemen hebt zou ik eerst kijken of de domificatie wel echt de bottleneck is, en indien dat zo is eerst indien mogelijk het aantal objecten in je model verkleinen (of bv data transfer objecten gebruiken).

[matthijsln]

Janoz schreef op dinsdag 19 augustus 2008 @ 11:06:
[...]

Dat hoeft niet. Door een DOM interface (achtig iets) op je objecten te zetten kun je het uitvragen alsof het een DOM is. Er is dan geen tussenliggende kopie nodig. . Dat scheelt een heleboel geheugen gebruik.

Waarom zou dit minder geheugen gebruiken? Of je de toXML() van alle objecten allemaal achter elkaar aanroept of pas wanneer de XSLT processor je objecten langsgaat?

Zoals gezegd hangt dit er helemaal vanaf of de XSLT processor niet alle nodes langsgaat. Gaat de XSLT processor wel alle nodes langs gebruikt het evenveel geheugen. Volgens mij zijn XSLT API's en implementaties niet gebouwd om geheugen-efficient met de source DOM om te gaan en zullen ze in bijna alle stylesheets alle nodes langsgaan.

Maar goed, meten is weten en premature optimization is the root of all evil , ik kan het mis hebben

[Janoz]

matthijsln schreef op dinsdag 19 augustus 2008 @ 11:49:
[...]


Waarom zou dit minder geheugen gebruiken? Of je de toXML() van alle objecten allemaal achter elkaar aanroept of pas wanneer de XSLT processor je objecten langsgaat?

In geval 1 moet je het resultaat van alle toXML() ook onthouden.. Je hebt dus al je data dubbel in het geheugen. In het tweede geval werkt de XSLT processor niet op het tussenliggende resultaat, maar op het origineel.

Zoals gezegd hangt dit er helemaal vanaf of de XSLT processor niet alle nodes langsgaat. Gaat de XSLT processor wel alle nodes langs gebruikt het evenveel geheugen. Volgens mij zijn XSLT API's en implementaties niet gebouwd om geheugen-efficient met de source DOM om te gaan en zullen ze in bijna alle stylesheets alle nodes langsgaan.

Wanneer je objecten zichzelf als nodes kunnen voordoen is het helemaal niet meer relevant. Alle data is al in het geheugen.

Maar goed, meten is weten en premature optimization is the root of all evil , ik kan het mis hebben

Mwah, dit noem ik persoonlijk niet premature optimization, mits er een (semi-) standaard oplossing voor beschikbaar is. De impact is namelijk behoorlijk hoog.

[matthijsln]

Janoz schreef op dinsdag 19 augustus 2008 @ 11:57:
[...]

In geval 1 moet je het resultaat van alle toXML() ook onthouden.. Je hebt dus al je data dubbel in het geheugen. In het tweede geval werkt de XSLT processor niet op het tussenliggende resultaat, maar op het origineel.

[...]

Wanneer je objecten zichzelf als nodes kunnen voordoen is het helemaal niet meer relevant. Alle data is al in het geheugen.

XSLT processors in java kunnen alleen maar met DOM objecten werken, dus die zullen hoe dan ook een keer geconstrueerd moeten worden.

Mwah, dit noem ik persoonlijk niet premature optimization, mits er een (semi-) standaard oplossing voor beschikbaar is. De impact is namelijk behoorlijk hoog.

Hangt af van de grootte van je model. Die grootte beperkt houden lijkt me het best. Je model zou niet veel meer objecten moeten bevatten dan wat daarvan in je HTML output zichtbaar is.

Daarnaast vermoed ik dat de XSLT transformatie een veel groter deel van de tijd opsoepeert dan de domificatie. Dat kan je bv optimaliseren door lange XSLT berekeningen in Java of SQL queries te doen en die resultaten in DTO's te stoppen etc.

[ Voor 11% gewijzigd door matthijsln op 19-08-2008 12:16 ]

[Vaudtje]

Janoz schreef op dinsdag 19 augustus 2008 @ 10:22:
@vaudtje
Waarschijnlijk gebruikt de XSLT parser XPath om zijn input in te lezen. Bij een Xpath navigable object model is er dan geen tussenliggende xml nodig. Het objectmodel manifesteert zich als een DOM dat rechtstreeks uitgelezen kan worden.

Xoverride zoekt dus een Java XSLT engine die een 'Xpath navigable interface' accepteert in plaats van een XML stream.
Als ik ff snel naar die Spring link kijk, kun je daar een DOMSource implementeren/vinden die rechtstreeks naar je model gaat.

matthijsln schreef op dinsdag 19 augustus 2008 @ 11:49:
[...]
Waarom zou dit minder geheugen gebruiken? Of je de toXML() van alle objecten allemaal achter elkaar aanroept of pas wanneer de XSLT processor je objecten langsgaat?
[...]

Het idee in dit geval is dat je dus helemaal geen XML serialisatie meer hoeft te doen, maar dat de XSLT engine zijn gegevens rechtstreeks uit het model trekt.

[ Voor 22% gewijzigd door Vaudtje op 19-08-2008 12:21 ]

[Janoz]

matthijsln schreef op dinsdag 19 augustus 2008 @ 12:14:
XSLT processors in java kunnen alleen maar met DOM objecten werken, dus die zullen hoe dan ook een keer geconstrueerd moeten worden.

Dat is geen juiste conclusie trekking. De processor werkt met DOM objecten, maar wanneer je model zich voordoet als DOM objecten hoef je niet een apparte DOM te construeren.

Ik zal het met een simpel voorbeeld proberen uit te leggen. Stel je hebt een CSV bestand. Je hebt ook een processor die een stylesheet heeft en de verschillende objecten met een x en een y uit die CSV data haalt.

Nu kun je je 2D array om gaan zetten naar een CSV document. Dat werkt. Wat je echter ook zou kunnen doen is een interface maken die iets hoger in je processor gehangen wordt. Zodra het template dan een x,y waarde opvraagt worden er geen regels en komma's geteld, maar wordt rechtstreeks de 2D array aangeroepen en die waarde teruggegeven. De processor merkt hier niks van, je hebt alleen de tussenliggende CSV data niet meer nodig.

Hangt af van de grootte van je model. Die grootte beperkt houden lijkt me het best. Je model zou niet veel meer objecten moeten bevatten dan wat daarvan in je HTML output zichtbaar is.

Ik zeg niet voor niks (semi-)standaard oplossing. De winst is hoe dan ook groot terwijl de risico's dan laag zijn. Voor een eigen oplossing wordt het plaatje inderdaad weer een stuk anders.

[Janoz]

Vaudtje schreef op dinsdag 19 augustus 2008 @ 12:19:
[...]

Xoverride zoekt dus een Java XSLT engine die een 'Xpath navigable interface' accepteert in plaats van een XML stream.
Als ik ff snel naar die Spring link kijk, kun je daar een DOMSource implementeren/vinden die rechtstreeks naar je model gaat.

Ik ben niet heel bekend met beschikbare oplossingen. Vandaar dat ik niet verder kwam dan 'Er zou wel iets moeten zijn'. Maar wat jij nu zegt klinkt inderdaad als de oplossing die ik in mijn hoofd had.

[Xoverride]

Vaudtje schreef op dinsdag 19 augustus 2008 @ 12:19:
[...]

Xoverride zoekt dus een Java XSLT engine die een 'Xpath navigable interface' accepteert in plaats van een XML stream.
Als ik ff snel naar die Spring link kijk, kun je daar een DOMSource implementeren/vinden die rechtstreeks naar je model gaat.


[...]

Het idee in dit geval is dat je dus helemaal geen XML serialisatie meer hoeft te doen, maar dat de XSLT engine zijn gegevens rechtstreeks uit het model trekt.

Ja die DomSource heb ik gezien, maar daarmee is het als het goed is de bedoeling om een xml boom terug te geven. Zoals ze ook in het voorbeeld doen:

code:

protected Source createXsltSource(Map model, String rootName, HttpServletRequest
        request, HttpServletResponse response) throws Exception {

        Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
        Element root = document.createElement(rootName);

        List words = (List) model.get("wordList");
        for (Iterator it = words.iterator(); it.hasNext();) {
            String nextWord = (String) it.next();
            Element wordNode = document.createElement("word");
            Text textNode = document.createTextNode(nextWord);
            wordNode.appendChild(textNode);
            root.appendChild(wordNode);
        }
        return new DOMSource(root);
    }

Er wordt letterlijk een boom gemaakt en als DOMSource geretourneerd. Ik kan dit dus niet als interface gebruiken. Verder heb ik geen ervaring met deze class, dus ik weet niet of het gebruikt kan worden als een soort .NEt versie van Xpathnavigable.

Het grappige is dat in de Spring documentatie bovenstaand voorbeeld staat. Dit zou suggereren dat je model naar XML transformeren de oplossing is binnen Spring.

Leuke discussie hier trouwens

[Vaudtje]

Xoverride schreef op dinsdag 19 augustus 2008 @ 12:50:
[...]
Er wordt letterlijk een boom gemaakt en als DOMSource geretourneerd. Ik kan dit dus niet als interface gebruiken.

Zoals je aan de methode declaratie kunt zien hoeft deze methode alleen een javax.xml.transform.Source terug te geven (er is bijv. ook een SAXSource). Je zou de methode dus anders kunnen implementeren, waarbij je je eigen interpretatie van Source teruggeeft, die alleen als facade voor je model optreedt. Alleen zie ik aan de Source interface niet veel aanknopingspunten, dus dan moet je wat dieper in de documentatie duiken om tot een zinnige implementatie van de Source interface te komen (ik vermoed dat je dan je model als een org.w3c.dom.Node moet gaan aanbieden).

[ Voor 7% gewijzigd door Vaudtje op 19-08-2008 13:22 ]

[matthijsln]

Xoverride schreef op dinsdag 19 augustus 2008 @ 12:50:
[...]
Ja die DomSource heb ik gezien, maar daarmee is het als het goed is de bedoeling om een xml boom terug te geven. Zoals ze ook in het voorbeeld doen:

...code...

Er wordt letterlijk een boom gemaakt en als DOMSource geretourneerd. Ik kan dit dus niet als interface gebruiken. Verder heb ik geen ervaring met deze class, dus ik weet niet of het gebruikt kan worden als een soort .NEt versie van Xpathnavigable.

Het grappige is dat in de Spring documentatie bovenstaand voorbeeld staat. Dit zou suggereren dat je model naar XML transformeren de oplossing is binnen Spring.

Dat wordt niet gesuggereerd, dat staat duidelijk in de documentatie. Voor XStream zou je denk zoiets doen (zie http://xstream.codehaus.o.../io/xml/TraxSource.html):

Java:

protected Source createXsltSource(Map model, String rootName, HttpServletRequest
        request, HttpServletResponse response) throws Exception {

    List words = (List) model.get("wordList");
    return new TraxSource(words);
}

Staar je je niet te blind op Xpathnavigable of het gebruiken van een interface of wat... Probeer eerst dit aan de praat te krijgen voordat je daarmee begint.

edit: deze code moet je nog wel iets aanpassen zodat er een root element met de naam "rootName" wordt gegenereerd door XStream

[ Voor 7% gewijzigd door matthijsln op 19-08-2008 13:49 ]

[Vaudtje]

matthijsln schreef op dinsdag 19 augustus 2008 @ 13:20:
[...]
Voor XStream zou je denk zoiets doen (zie http://xstream.codehaus.o.../io/xml/TraxSource.html):

Inderdaad doet deze TraxSource wat ik net suggereerde:

quote: http://xstream.codehaus.o...am/io/xml/TraxSource.html

A JAXP TrAX Source that enables using XStream object serialization as direct input for XSLT processors without resorting to an intermediate representation such as text XML, DOM or DOM4J.

Je kunt dus je XStream objectmodel gebruiken zonder eerst een XML text stream te maken

[matthijsln]

Vaudtje schreef op dinsdag 19 augustus 2008 @ 13:27:
[...]

Inderdaad doet deze TraxSource wat ik net suggereerde:

[...]

Je kunt dus je XStream objectmodel gebruiken zonder eerst een XML text stream te maken

En deze Source is zelfs een SAX Source, dus bouwt niet eerst een hele DOM tree op: misschien zelfs een niet-merkbaar minder geheugenverbruik

edit: wat is wat je zei

[ Voor 5% gewijzigd door matthijsln op 19-08-2008 13:34 ]

[Xoverride]

Dat is het! het werkt als een trein TraxSource is dus de oplossing. Dit is mijn uiteindelijke code waardoor ik dus nu mijn domain objects in mijn XLST beschikbaar heb:

code:

    protected Source createXsltSource(Map model, String rootName,
            HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        
        List container = (ArrayList) model.get("container");
        
        TraxSource source = new TraxSource(container);
        
        return source;      
    }

Thanks alot

[ Voor 8% gewijzigd door Xoverride op 19-08-2008 14:42 ]

[Vaudtje]

_{Nu nog even casten naar List ipv ArrayList en je bent klaar
[/zeurmodus]}

[Xoverride]

Vaudtje schreef op dinsdag 19 augustus 2008 @ 16:20:

_{Nu nog even casten naar List ipv ArrayList en je bent klaar
[/zeurmodus]}