cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 19:05:31 GMT
BURGHARD Éric wrote:
> Stefano Mazzocchi wrote:
> 
> 
>>BURGHARD Éric wrote:
>>
>>
>>>WAIMS (where am i missing something ? :-)
>>
>>XSP was designed to achieve exactly what you are describing. Sure it has
>>some limitations and the use of xslt to generate java code is not
>>exactly appealing, but it supports exactly that programmatic model.
>>Still everybody seems to hate it (I still use it, but only as a faster
>>way to write custom generators, not as a template language).
>>
>>I think the reason is that what you want to achieve seems practical, but
>>it normally turns out in hell.
>>
>>Example: the difference between <get-users/> and ${get-users} is that
>>the first invoques a function (thus could trigger an exception) the
>>second refers to a variable, which, at worst, might be unset or empty or
>>contain a wrong value.
>>
> 
> 
> Understood. The difference is subtile. <get-users/> is a data from the user
> point of view (he can put it inside a variable), but its true that the
> component responsible for returning the value might trigger an exception
> and i'm agree this is bad because we are already in the "view space". Well
> thought.
> 
> But jx (with his ability for calling method on java objects), is not anymore
> a pure view template language. $session, $request, ... are already objects
> not dom nor pure bean objects.
> 
> 
>>As soon as you realize this, you also realize that you need conditionals
>>in your language semantics... and if you hit the <if> tag, you are dead.
>>
> 
> 
> Yep.
> 
> 
>>What you are asking for are not taglibs but functional macros... the
>>ability to invoque a function/service/method instead of just reference a
>>variable... this allows you to drive the control directly from the
>>template, instead of having the control inverted by the flow controller.
>>
> 
> 
> I never a thought about the MVC design because actual jx implementation is
> already outside of this pattern. I'm totaly happy with the functionnal
> macros name ;-)
> 
> 
>>I think this is a reasonable request and I see nothing wrong in it, but
>>these have nothing to do with taglibs, are more similar to what input
>>modules are for a sitemap.
>>
> 
> 
> Ok. So what about turning on the ability to pass dom inside sitemap
> parameters ?

Hmmm, I don't have a problem in passing more structured data-structures 
as sitemap parameters.

> 1) pipeline more clear
> 
> <generate type="jx" src="..">
>   <parameter name="auth" dom="{session-context:authentication}"/>
> </generate>

but I don't like dom="", I don't think we have to type them.

> 2) servicemanager, $request, $session useless in jx (pass parameters
> explicitly in the sitemap like you use to do with SendPage in flow). SoC
> preserved.
> 
> 3) inversion of control not broken. (Exception triggered from the sitemap).
> You can remove java object access from jx since they are used for breaking
> this IoC and SoC.
> 
> We use to do (well, a bad habit :-)
> <jx:set><jx:import src="cocoon:/userprofile"/></jx:set>
> inside templates. This break SoC and IoC too.
> 
> Oceatoon (tibor ;-) make me think of another advantage of passing dom with
> parameters.
> 
> <generate type="jx" src="..">
>   <parameter name="userprofile" dom="{cocoon:/userprofile}"/>
>  ...
> </generate>

uh, that's pretty cool I have to say.

> which is much more readeable and doesn't break anything.
> 
> WDYT ?

+1 as long as you don't call it dom="" but you leave it as value="" and 
you let the consumers deal with their type checking (don't know if this 
is at all possible, but you get my idea).

-- 
Stefano.


Mime
View raw message