cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <eric.burgh...@systheo.com>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Wed, 26 Jan 2005 08:37:59 GMT
Reinhard Poetz wrote:

> Two days ago, I wrote about my usecase for chained input modules. Daniel
> answered, that in his opinion this looks like voodoo and suggested to have
> a global action that is executed for every request. Wouldn't this be the
> solution for passing objects to the view layer either?
> Currently JXTG gives access to the session, the request and the
> application context. So using them as container is possible today. The
> drawback: The contract isn't defined very well because in your template
> you have to to something like this:
> 
> <p>${cocoon.request.getAttribute('xyz')}</p>
> 
> A weak contract IMO.
> 
> Having a strong contract like
> 
> <generate type="jx" src="..">
>    <parameter name="userprofile"
>     object="{$cocoon.request.getAttribute('userprofile')}"/>
> </generate>
> 
> could help us to make templates more side-effect free because then we
> could forbid the direct access of the request and the session from within
> templates:
> 
> <page xmlns:jx="...">
>    <p>{$userprofile.getName()}</p>
> </page>
> 
> We could even go a step further and enforce explicit variable declaration:
> 
> <page xmlns:jx="...">
>    <jx:variable name="userprofile"/>
>    <p>{$userprofile.getName()}</p>
> </page>
> 
> Unfortunatly those templates wouldn't still be side-effect free, because
> nobody prevents me from doing
> 
> <p>{$userprofile.getRole().setName('newRoleName')}</p>
>

Yeah, and that's why IoC and SoC are already broken in jx. But as i use to
say if you want to break SoC and IoC you could do it whatever the
implementation. Even a simple <jx:import src="cocoon:/getuser"/> break IoC
because the view request something to the controler.

At least if you restrict the kind of object you could pass via the sitemap
parameters you could prevent side effects on workflow objects (session,
request, userprofile) without beeing force to deprecate java calls which
seems to be usefull for some java.util.

> 
>> And as said I feel
>> more for polishing the flowscript way, than being part of developing
>> alternative solutions.
> 
> Maybe you can comment on my response all the same :-)
> 

WDYT ?



Mime
View raw message