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 Tue, 25 Jan 2005 11:45:48 GMT
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 ?

1) pipeline more clear

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

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>

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

WDYT ?


Mime
View raw message