Conal Tuohy wrote:
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.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
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.- 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).
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¶m2=bar
then the flag links should look like: http://myhost.com/site/mypage?param1=foo¶m2=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 [EMAIL PROTECTED]
