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 18:33:34 GMT
BURGHARD √Čric wrote:
> 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 :-)

You should care:, at least if you 
want to avoid extensive flaming ;)

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

Ok, I happen to have some strong opinions about this that certainly not 
is shared by all people in the community. First I think that CForms is 
great in many ways and does an excelent job. But IMO its architecture is 
a severe mixture of concerns and rather monolitic. There is no clear 
separation between model, view and control. IMO it should never have 
emited any SAX events at all. Producing XML is a concern for the view 
layer e.g. a set of JXTG macros. If it had been a "passive" model it 
would have been much easier to write the JXTG macros and no hacks would 
have been required.

In general I believe that if you have a model that is hard to write a 
view against it is better to write an adapter in Java that makes it more 
"viewable", than doing a lot of programming in the template, I think it 
gives better SOC.

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

I agree that flow currently is inconvinient to use for such cases. But I 
think that rather than solving this by having all sorts of control 
functionality in the view we should make flow easier to use for such 
cases. I think that a (flow)script action as I described in and 
that others also have proposed, would decrese peoples reluctance in 
using flow for somple cases. I mean writing:

doIt() {
   return { data: entityFromDatabase(),
            skin: request.getParameter( "skin" )};


<match pattern="foo">
   <call function="doIt"/>
   <generate type="jx" src="foo"/>

shouldn't feel like an impossible task.

We could also have something like the pluggable object model that 
Carsten proposed.

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

Of course you can, but I don't want to deliver the rope that our users 
can hang them selves in.

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

So was I, hopefully it will work much better in the refactored JXTG.

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

No, I just don't see the reason why we should have easy access to all 
the side effect things in flow, the getters should be enough IMO.

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

Wouldn't accessing your data oject in a one line (flow)script action as 
described above and viewing it in JXTG be a clean solution?

> The flow
> retrieve only data that let it to choose where to go, and jx retrieve data
> that are for displaying purpose only.

I think a (flow)script action is good for the retrieving part. But I'm 
not going to be impossible, if there are good enough resons for using 
the service manager in JXTG we should allow that, but I'm not convinced 

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

Might be reasonable, but I got so much flaming when I proposed that so I 
don't feel like pushing it anymore.


View raw message