cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <>
Subject Re: servicemanager and jxtg (was: WishFull thinking JX and SessionContext Authentication)
Date Sun, 23 Jan 2005 15:57:43 GMT
Daniel Fagerstrom wrote:

>> 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.

Ok excuse me, i apparently misuse the word taglibs. I just don't care (for
now :-) if the tag is implemented as a jx:macro or a java instance. For me
a file defining several macros was kind of taglib (add some usefull tags).

Now i'm very suprised with this java taglibs aversion (not yours :-). When
you look at sylvain's code, for example, he needed to do something that he
couldn't express with jexl or jxtemplate (a form is not a kind expression,
anyway). So he put an xmlconsumer in the $cocoon map, add an helper class
plus some jx blackmagic (not a criticism, i find that smart and very
usefull), but he certainly could do that, much more efficiently and
understandable, with a well defined jx taglibs API (again i'm happy with
current implementation and thanksfull to you cocoon community, just want to

> 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?

I thought about just accessing some components functionnalities like getting
an instance of ContextManager for retrieving  the dom of a session context
(just getters). I know that i can do that with flow, but most of our pages
are standalone (ie flow is reduce to a unique SendPage).

Our issues concern only templating: get blindly some data (logic is, and
should rest, in components). Access to some part of the retrieved data is
still done with jexl or jxtemplate.

>> 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

I think, personnaly, that  you shouldn't restrict things like that in. If i
want to break SoC paradigm, i can do that with any implementation. I was
really disapointed as user, after discovering how flow and jxtg were tied
together (you can pass object references !), when i realized that the
$cocoon objects were in fact totaly different between the 2 environnements.

I think that the continuations facility is strong enough to enforce people
using flow for logics. For the rest (and because they are so tied) keep the
OM homogeneous between jx and flow, and let people choose. I don't want to
go through flow, if i don't need continuations (ie. no logics), just to
retrieve some basic data via components.

We use eXist here, and i can easily imagine to add my own jx:macros for
accessing some data on some common xml resources in a "clean way". It's not
bad to do that in jx if the retrieved data plays no roles in logics, but
are just for templating purposes. With a jx component manager i could do it
the same way than i use to do in flow or java (otherwise i still can do it
but with blackmagic).

By allowing me to do that via servicemanager, you give me the oportunity to
separate concerns even better and keep my flow & jx cleaner. The flow
retrieve only data that let it to choose where to go, and jx retrieve data
that are for displaying purpose only. Now when i'm happy with my jx:macros
(which are tags), i could choose to implement them in java (taglibs :-),
and/or share a component (which give access somehow to somedata) for
reusing code (efficiently) between my jx and my flow.

>> 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).


What do you think ?

View raw message