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 Mon, 24 Jan 2005 16:27:57 GMT
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.

> 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

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

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

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

View raw message