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.
