cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: why JXTG sucks? was: FreeMarker integration
Date Thu, 12 Aug 2004 00:10:30 GMT
Conal Tuohy wrote:

> Leszek Gawron wrote:
> 
> 
>>If I follow what you propose my model would have to covert every 
>>wikified string property even if view does not need it. This 
> 
> 
> No ... only that it should be ABLE to convert the property to a DOM whenever the view
DOES need it. If your view never requests it then the conversion would never take place. e.g.
http://jakarta.apache.org/commons/jxpath/users-guide.html#Containers
This is something similar to a proxy pattern I use sometimes to compute 
some heavyweight model data only when needed. I do not want my POJOs to 
be dependent on Container (I should not intruduce JXPath dependency only 
for that - I could switch to a view generator that does not use JXPath 
at all). So I would have to wrap every of my entity at runtime after 
fetching the entities from database. This would break my object graph as 
well as lazy loading.

>>- the domain of projects you implement. Looks like your 
>>experience comes 
>>more from publishing/authoring projects rather web applications that 
>>expose a lot of dynamic views and big data model underneath. A data 
>>model for me is not DOM, not documents, these are POJO 
>>entities mapped 
>>from database relations. 
> 
> 
> Well ... I have experience with database web-apps as well as publishing apps, and I think
you're mistaken about these Wiki-text properties - I think they really ARE documents. Your
database actually includes (small) documents as well as more primitive data types. Look at
it this way, and it makes sense for your model to expose these documents as DOMs (but you
don't need to persist the DOMs in Hibernate - they can be computed (parsed from Wiki-text)
whenever the JXT accesses them).
You may be right here. Still DOM is not needed here as in view I have 
access to xml consumer directly so I can create a formatter that creates 
SAX events without any intermediate form.

Plase take into account that this is just an example of functionality 
that I would like the view to be customly extended with.

Another one that has even got nothing to do with data model but is a 
view extension that I required once: My user needed to switch locales 
easily. To do that every page has been rendered with a few flag icons. 
The pages were rendered in some state that was described by request 
parameters. So if you have been viewing something like:


http://myhost.com/site/mypage?param1=foo&param2=bar

then the flag links should look like:
http://myhost.com/site/mypage?param1=foo&param2=bar&locale=pl

This would render the page with exactly the same content but localised 
differently.
The problem: some of the parameters are in URL, some are POSTed. You 
need to create a link to current page and append all request parameters 
to it. You could imagine that the link is also created with some 
additional parameters fetched from session etc.

Do you do that in controller and provide data via model ? No. The 
controller does not know what links the view will generate. In this case 
it knows one link - to the same page. But does not know about any others 
  (links to external site that locale was also supposed to be transfered)

Do you do that in JXTG directly? No. The jx:macro is limited and 
probably you will not be able to provide this functionality. Even if you 
did it feels somewhat slow for this kind of processing.

Do you use transformation for this? No, you already have a lot of custom 
transformation steps to cover hacks like these. You do not want to 
create a custom transformer for every 3-liner functionality.

What do you do ? you create a stupid static method that gets 
cocoon.request and spits out string with url. You access it directly via 
${Packages.com.mypackage.SpecialLinkGenerator.generateLinkFromRequest( 
'', cocoon.request )}

is it clean and elegant ? hell no ..

What you should be able to do is to plug this implementation into view 
directly, declare the name and parameters this function takes and call 
it via some view specific syntax. Then you would have for example
<@localeAwareLink href="http://othersite.com/thepage?additionalParam=1" 
request="${cocoon.request}"/>


this localeAwareLink "macro" could even have access to ObjectModel so 
you do not have to pass request here because it can query for it if it 
needs it. It could be just:
<@localeAwareLink href="http://othersite.com/thepage?additionalParam=1"/>

-- 
Leszek Gawron                                      lgawron@mobilebox.pl


Mime
View raw message