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 hard-bop.com http://www.hard-bop.com
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
