cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: servicemanager and jxtg (was: WishFull thinking JX and SessionContext Authentication)
Date Mon, 24 Jan 2005 05:22:32 GMT
I think the important thing to remember is that JXTG should be used for 
injecting data. Regardless of whether it is called directly through the 
sitemap or through flow it should allow access in a consistent way to 
session, request and other objects that are necessary to injecting data 
into the view. If you need to look up data from a database or other 
source, authenticate users or make decisions on what data to present, 
it should be done before using JXTG.

On Jan 23, 2005, at 12:33 PM, Daniel Fagerstrom wrote:

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

Hopefully we all got that out of our system. ;-)

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

Since CForms is an integral part of Cocoon, maybe it is time to handle 
them directly in JXTG and not with macros. I don't know.

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

Why not just use a generic function and pass parameters from the 

> 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" )};
> }
> and
> <match pattern="foo">
>   <call function="doIt"/>
>   <generate type="jx" src="foo"/>
>    ...
> </match>
> 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.
> Yes.
>>>> 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.
>> 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.

JXTG is meant as a simple solution. It provides plenty enough rope to 
hang oneself as is. I'm always amazed at the ways I can come up with to 
do things in the template that are better done in Java.

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

I think this should be obvious, but then again, it obviously isn't. ;-) 
Even plain old flow is cleaner. I guess some people just like xml 
better then javascript. ;-0 Maintaining one file instead of two is 
obviously simpler. The price is a more complex file and in this 
particular case a more complex system to learn. Complexity cannot be 
removed, only shifted. IMO, a simple templating language is what we 
should be aiming for. The methods cocoon provides for data access are 
sufficient and simple enough for most use cases.

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

I don't want to restart the discussion on taglibs, but there is an 
existing method to do this. Its using flow and JXTG. I don't really see 
what the big deal is with having two files. A change in how or where 
(URL) data is accessed does not have an effect on how or where in the 
template it gets injected and vice versa. The fact that one does not 
affect the other shows clearly that these are separate concerns.

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

Good. :-P

> /Daniel

Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message