cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: servicemanager and jxtg (was: WishFull thinking JX and SessionContext Authentication)
Date Sun, 23 Jan 2005 10:03:47 GMT
BURGHARD √Čric wrote:
> Daniel Fagerstrom wrote:
>>During the "JXTG 2.0 (just say no!)" (you find links to it in
>>, many people where negative to
>>the idea of developing JXTG in a "taglib" direction. We decided that
>>JXTG should focus on templating and that more programatic stuff should
>>better be done in flowscripts.
> It's strange, because I think that sylvain, with his cforms jx macros shows
> how usefull could be a taglib for templating purpose.

We are certainly going to keep macros. The question was rather if we 
should have some mechanisms so that it would be easy to add own tags 
written in Java, based on bad experience with taglibs in e.g. JSP, 
people didn't want that.

Thew idea is that the template should focus on the view aspect. AFAIK 
the main use for having access to the service manager would be to be 
able to create objects in the template and in most cases this is more of 
  a control concern and would better be done in a flowscript. If you 
have use cases where using the service manager in the view make sense, 
we can discuss them.

> Perhaps do i need to
> make my own helper class, to hide the connexion between jxtg and om, but i
> would prefer to do it directly inside jx macros specially if the
> "connexion" has no programatic stuff in it: a simple method call to a
> component to retrieve a string or dom for example (ie quite similar to a
> jx:set with a jxtemplate expression).

Can't you do that in the JXPath or Jexl expressions?

> Perhaps input modules inside jx could also solve our problem without
> changing the actual jxtg (fuzz) focus (<- just joking jxtg is a great
> thing :-)

Might be, there seem to be a need for making more things available in 
the expression context. Question is if that should be done with input 
modules, pluggable environment or a flowscript call.

>>So I don't think you would get much support for some more general move
>>in making it easier to do "programming" in JXTG. But we can of course
>>discuss more specific use cases and see if they view concerns that
>>should affect template development or if they are control concerns and
>>in that case how they could be done in flow.
> But as far as i understand your work, if you had made a uniformization
> between flow and jx behaviors, does this mean that the $cocoon objet will
> behave similary than the one in flow (ie had a getComponent method :-) ?

Not exactly, I was a little bit vague. The idea is making the FOM _view_ 
from JXTG available in other places in Cocoon. Not making the whole FOM 
available. I don't want more side effects than necessary avaliable in JXTG.

> Will test your JXTG 2.0 with real pleasure.
Thanks :) But we don't have any code ownership here and other people are 
also involved (you, by joining the discussion for example).


View raw message