BURGHARD �ric wrote:
Different alternatives to JXTemplateGenerator has been discussed in a number of (long) threads, some of them cited at http://wiki.apache.org/cocoon/Templates. And the conclusion was that we think that JXTG is good enough for our needs, but that it needs refactoring to be easier to support, refine and possibly extend for the community. I'm currently working on refactoring it (and would be happy if others joined).hi everybody,
I'm a little disapointed by all theses xml languages we can found around which nearly all do the same things.
1) Last time i wanted to construct a project with maven and i found jelly. it had a rich tag library, handle jexl expressions, and can handle xpath through tag's libraries. But, as maven users, you all know that.
So my question (na�ve), is why not using jelly (jelly generator) instead of redo the work with jxtemplate. I wonder why using ant mutant anteater too, because IMHO testing with ant+jelly+junit+http(client) is much more powerfull (multipart post, upload file, ...). And we could certainly define a new tag library (macros) and run the anteater scripts "as is" with jelly.
As you can see in some of the threads people are quite negative (or even aggresive towards) taglibs. So being able to easily write own taglibs is not part of our requirement list.
When it comes to using a JellyGenerator both Carsten and I have done some work on that and wasn't particulary happy about it. OTH Peter Royal had more success http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110225841413218&w=2. But the community just didn't show any entusiasm at all about basing our work on Jelly (or other externally developed frameworks).
A large part of the implementation of a template language is about integration with the underlying framework (Cocoon), so IMO it makes sense to have an own template language even if I thought it was an instance of "not invented here" first.
2) I play last time with saxon8 and xpath/xslt2.0. I found that it looks much more like a programming language than ever (well it's still xml). I like the simplified stylesheet syntax, which allow you to mix the document and the stylesheet into one document (like jx).
So is there any plan to add an xslt2.0 generator. Think about a generator which add some context variables (like $cocoon), or give access to protocols (like cocoon:/) inside in your template.
This has also been discussed in detail: http://marc.theaimsgroup.com/?t=104930795600004&r=4&w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2 http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105178436429214&w=2
Problems with using XSLT2 or XQuery is that at least two years ago the licence of Saxon (MPL 1.0) was not considered to be compatible with the Apache License so Cocoon can (could?) not be bundled with Saxon. And Xalan does not implement XSLT2 or XQuery yet.
Also an important requirement is to be able to access bean structures from the template language. This can be done from Xalan or Saxon (as discussed in the above threads), but it is not that easy to control efficency. Then Chris Oliver implemented JXTG so there was not much reason to continue these issues.
Might be, and I argued for both the XSLT and Yelly solution before, but I have changed my mind as it wasn't that easy in practice.these 2 candidates have a bigger audience than jxtemplate.
/Daniel
