Peter Hunsberger wrote:
On Sat, 05 Mar 2005 11:52:58 +0100, Daniel FagerstromThe main use case is to unify script access to environment data like the request object.
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
<snip/>
This is more of a RT than anything concrete for or against the ideas given so far.
As I follow this discussion it keeps striking me that we're more-or-less reinventing resolvers and sources at a slightly lower level. At one level, people need:
protocol://x/y/z
to resolve to some XML/SAX stream fragment. Now we want
module.x.y.z
to resolve to something that isn't always XML but can be used to
create a SAX stream or can be traversed with some kind of expression
language.
Sources are designed for giving access to streams (and due to eficciency reasons SAX streams) and the "object accessors" are intended to give access to script friendly POJOs. The streams and SAX streams are consumed by parsers or event handling code, while the POJOs are accessed by ELs and scripting languages that typically use reflection mechanisms. That is quite a large difference.
Even if there are similarities at a more abstract level I don't see what
we would gain by trying to merge the concepts at the implementation level.
It's not so much a merge as a change in mind set: don't promote script access to POJO's at all;
The "object accessors" are used in a configuration file to put together a script OM, like e.g. the FOM. If we have such script friendly OMs it would be quite easy to build a XML source based on that by using e.g. Castor. IMO the ideas discussed in this thread will make it easier to do what your asking for.instead encourage production of XML via POJO wrappers feeding XSLT.
The problem is not graph traversal. The problem that I talk about is, that for many applications you have a rather large Java bean structure e.g. the FOM and you are only going to access a small part of it. Serializing the whole Java object to SAX and then select the few data that you actually needed in XSLT becomes ineficient.XSLT is my number one tool for building Cocoon based webapps, so whatSo on one hand, we've got source resolvers and xpath and on the other hand we've got factories (hidden or not) resolving to object modules and some expression languages.
I can't help but have the feeling that if XSLT was easy we wouldn't
be having this discussion at all. Stefano once proposed an alternate
XSLT syntax, but I think the issues of understanding a declarative
language wouldn't go away.
you suggests certainly doesn't apply to me. IMO the main reason that we
are not using XSLT for accessing object graphs is that current XSLT
implementation not are particullary well suited for solving that task.
XSLT as language could certainly be used for it, but the current
implementations are specialized for being efficient for SAX inputs. And
rather hard to use for anything else.
Hmm, I don't see this. Can you explain more what problems you run
into? We build very complex graph resolution logic into XSLT. Properly used it seems much better than Java or a scripting language
for graph traversal? (and I've written code in many, many languages
over the years...)
A better solution is to use a lazy DOM adapter for the Java object that use reflection on the part of Java data structure that are needed instead of on all of it. You can find details about this approach in the "[RT] the quest for the perfect template language" http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2 and follow up threads. Now a problem with such an approach is that there are no, AFAIK, good lazy DOM adapters. And AFAIU Saxon and Xalan doesn't handle DOM input as efficient as one would hope, they build internal models of the DOM even if it shouldn't be needed. So in the end, according to my experience (I spent a lot of time on the task two years ago), it is much more work than it seem like and its questionable if the result would be that good.
Compared to that having a minimal template language (e.g. JXTG) that use an EL is much simpler way to solve most of the use cases.
If someone feel like making it easier to use XSLT as a template language I'm all for it, but I have lost the interest in doing it my self.
No, we are not discussing anything like that. What we are trying to solve is that you have different models for accessing basic environment data in the sitemap on hand and in flow and JXTG on the other hand, we want a common reusable model, that's all.Personally, I wonder if any of what is being discussed is reallyIt should be clear be clear from this thread what use cases we have in
necessary;
mind. If you have better suggestions on how we can achieve them, please
go ahead and tell us.
Actually, the real underlying use-cases for script based EL's isn't really that clear. The best I can come up with is the conditional production of some XML/SAX fragment that is expensive to produce (so you want to avoid it if possible). Even then, I can't see a real reason why branching flow with EL works better than branching flow with conventional pipelines (and perhaps some I/O module replacement).
Using JS as standard EL in Cocoon is Sylvain's idea so he can give a much better description of the advantages than I can (especially as I'm not completely convinced yet ;) ). But I'm quite certain that he doesn't have something like what you describe in mind.
The object accessors and the "unified environment model" have nothing to do with my RTs about how to simplify Cocoon web service orchestration that I have discussed in other threads (Terms like environment are far to overloaded :/ )Certainly Web services requires no POJO scripting, SAX production to a standard pipelines works just fine? (Though flow script helps).
I see. Even if you can't contribute code it would be much easier for people, how are able to contribute coding, to evaluate you ideas if you wrote something more like a design document.I'd love to see the Cocoon community put a stake in theSo would I. But my itch is not strong enough for actually make it
ground and build a good set of XSLT authoring tools and XSLT function
and document support capabilities and say "the way to data
manipulation and transformation with Cocoon is XSLT!"
happen, is yours?
Well, that's the thing; we already have this. You don't really have to add anything to Cocoon to make it happen... A POJOSource/Generator pair that took any random POJO and used introspection to generate a SAX stream might be fun, but I can't see the need; getting SAX out of any POJO isn't really hard. Having a said that, there are things that Cocoon could use to make this easier for the average user.
We've got a solution that works for us. Unfortunately, our institution
has a problem contributing directly to open source projects. Basically, we're non-profit and one of the ways we get funding is by
licensing our innovations back to interested parties. As a result
I've not had any luck getting permission to contribute directly back
to any Open Source project. The best I can do is random code
fragments in the mailing list and ideas...
Given that doesn't seem likely to happen,
You can make it happen if you want to.
I guess the only thing I canAFAIK there is no existing xpath traversal machinery in Cocoon that we
suggest here is that everyone should take a step back and make sure
the existing Cocoon machinery for source resolving and xpath traversal
isn't re-usable in some way before inventing anything new...
could reuse. Part of the proposal is about having such a reusable EL
mechanism based on the pluggable ELs from template, and about making the
"script environment" more reusable.
I can't really see a good way to use the existing code base either, but I threw the idea out since there might be others who have more experience with the Cocoon internals who might think of something.
ok.
/Daniel
