Of course you can do what you like, but just so you know, here is my point of view:
Obviously it would have been easy to make the expression language pluggable. I intentionally did not do that but rather decided to specifically support Jexl and JXPath.
The reasons:
- Both Jexl and JXPath are IMO quality Apache projects that deserve to be reused - and I enjoy building on the work of others which, to me, is one of the best aspects of open source software development.
- Two fundamentally different types of objects are typically passed to the template, namely Java Beans and XML documents. Jexl works well with the former but not the latter. The opposite is true for JXPath. However JXPath provides a bridge between the two for those cases where it is necessary to access both models in the same expression. It is naive in my opinion to assume that unifying to a single expression language is an actual achievement unless that language is suitable for accessing _all_ the object models you are using (maybe like this one: http://research.microsoft.com/~emeijer/Papers/XS.pdf). However, to my knowledge no usable implementation of such a language exists. The combination of Jexl and JXPath is minimally viable for JXTemplateGenerator IMO and if I were to vote I would -1 eliminating either one of them.
I intentionally did not provide a Java language "taglib" interface like that in JSTL, but instead provided a macro language as in Velocity. The primary reason was that Java tags cannot be optimized the way macros can. Just look at the implementation of the Cocoon taglib block for a good example of how to get terrible performance in your template processor (it does componentmanager (or servicemanager or whatever it's called now) lookups at runtime just to determine if a given tag is really a Java "taglib").
I also saw some comments about how you shouldn't put presentation markup in your templates but instead use XSLT, etc. The reason given was something to the effect that you would have to go change all your templates if your site design changed.
Um, hello, you _can_ avoid this by using <jx:import> and macros (that's what they're there for - namely to factor out reusable parts of your templates so they can be managed in one place). It seems a little silly to me to suggest that you _must_ use pipelines and XSLT to get reusability and managability. I mean, any decent programming language provides subroutines and libraries.
As regards the programming language like constructs, <if>, <forEach>, etc (borrowed directly from JSTL), those are there simply as navigational tools for the object model (to navigate repeating data and alternative - choice, optional - data) and _not_ to write computations as in a real programming language.
The funniest post of all was this http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2.
I mean, give me break. That is just plain silly.
I never realized inner classes were so _scary_. (The reason they are there is that JXTemplateGenerator predates blocks and also that the majority of those classes are unencapsulated "flyweight" objects that are managed by the enclosing template processor class.) If you insist on making them external classes please make sure they aren't public.
- Chris
