On Jan 23, 2005, at 12:33 PM, Daniel Fagerstrom wrote:
BURGHARD Éric wrote:Daniel Fagerstrom wrote:
Ok excuse me, i apparently misuse the word taglibs. I just don't care (forIt'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.
now :-)
You should care: http://marc.theaimsgroup.com/?t=110210719800001&r=2&w=2, 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. AFAIKI thought about just accessing some components functionnalities like getting
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?
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 sitemap?
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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110640904407297&w=2 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.
I think, personnaly, that you shouldn't restrict things like that in. If iBut 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.
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 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
