cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject JXTemplateGenerator
Date Fri, 10 Dec 2004 16:29:05 GMT
I recently took a look at this mailing list after I happened to talk to 
Stefano in person (he was in LA) and noticed a _few_ posts about 
refactoring JXTemplateGenerator.

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



Mime
View raw message