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 19:41:23 GMT

On Jan 24, 2005, at 10:27 AM, BURGHARD √Čric wrote:

> Glen Ezkovich wrote:
>> 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.
> Injecting data is the point, but for me "looking up data from a 
> database" is
> quite like "injecting data". Just it's not from session but who cares.
> Passing through flow for something that has nothing to do with logic, 
> and
> because it's not in session, just let me think that there should 
> certainly
> exist a better way.

Flow is not just about logic its about control. Flow is one of Cocoon's 
controllers. The controllers role is to mediate between the view and 
the model. Data access is a concern for the model not the view. I'm not 
sure why if you have static data you would need flow or JXTG. If your 
data is dynamic and needs to be accessed on a per request basis then 
you have entered the realm of the model. Flow is one method (and the 
recommended method) to access the data contained in the model.

>> 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.
> So move forms block to core or move jxtg to forms ? In fact i'm quite
> satisfied with your answer because it shows clearly that there's some
> needle in the foot of jx. Perhaps it's time to define a plugin API 
> around
> jxtg so you could preserve actual block separation (which i found 
> really
> great).
>> Why not just use a generic function and pass parameters from the
>> sitemap?
> I know how to factor things. It's not a matter of some sort of naming
> conventions (call your flow function with the same prefix than your jx 
> and
> your pipeline).

Thats not what I meant. One flow function gets passed URLs for files or 
DBs or whatever declared as sitemap parameters.

>  The point is to go through flow without really needing it
> (in the SoC sens if we're both agree that flow is dedicated to logic). 
> But
> sure i need to, if things stay like that.

Flow can be used for very simply things or very complex things. Its 
there, use it. And Flow its not just dedicated to logic its dedicated 
to playing the role of the controller in an MVC implementation.

>>> 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.
> Sorry. I was warned ;-). The templating will stay exactly the same. 
> Not more
> or less complex, at least for users. Just extensible. Sylvain is not 
> the
> only one on the earth who had good reasons to "extend" jx (by good i
> suppose that cforms macros are on the repository not only because 
> sylvain
> is a comiter :-), and we are quite agree to say that he did it by the
> cleanest way he could (but IMO not the cleanest due to design flaws).
>> 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
> Nothing new, we all know that. That's not the issue.
>> 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.
> What's the big deal of having just one file instead of two, specially 
> if the
> refactor needed to do that doesn't compromise simplicity nor break the 
> SoC
> paradigm ?

But it does. Thats where we disagree.

>>> Might be reasonable, but I got so much flaming when I proposed that 
>>> so
>>> I don't feel like pushing it anymore.
>> Good. :-P
> Sad to be flamed for such things. (But i'm smiling anyway ;-). Please 
> push
> it, i'll push it with you. I feel that good ideas seems to emerge from 
> this
> discussion.

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