cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTemplateGenerator
Date Fri, 10 Dec 2004 23:54:48 GMT
Christopher Oliver wrote:
> 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.

The main reason for making expression languages (EL) plugable is that 
ELs are used in many places in Cocoon. If we define a common inteface 
for using an EL and for giving a context for an EL we could get rid of 
duplicated code and ensure that ELs are used in the same way everywhere.

Although other ELs has been mentioned at the list I would guess that our 
"oficial" recomondation would be that users stick to Jexl and JXPath.

> - 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: 
> 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 think there is an agreement on the list on supporting both, based on 
the reasons you mentioned above. Some people suggested earlier that it 
would better to stick to one EL (the suggesters favourite one normally 
;) ), but it soon become obvoius that it would be unrealistic.

> I intentionally did not provide a Java language "taglib" interface like 
> that in JSTL, but instead provided a macro language as in Velocity.

I sugested that we should use "externally defined Java tags" (I don't 
use the term taglib anymore as it evoked bad emotions from some people). 
One reason for this is that I want to gather the code that implements a 
tag to one class, instead of having it placed in a tag class, in the 
parser and in the execution method. This to make it easier to see whats 
going on in the code and simplify support.

Another reason is that it often has been sugested that we need a 
replacement for XSP. And I thought that it could be a good idea to 
implement the few things from XSP as external tags to JXTG. Also there 
are plenty of transformers that basically implement a set of tags and 
where their actual function is hidden in all the event handling and 
state machine code. Here I also though that it would be easier to 
implement such things in the future by providing a tag interface.

But a lot of people seemed to think that it would be very bad for Cocoon 
to allow such things. So I still think that I will gather the code for 
each tag to one class with a common tag inteface, but not providing any 
mechanisms for users to import their own Java tags. That should keep 
everybody (except some users maybe ;) ) happy.

> The 
> primary reason was that Java tags cannot be optimized the way macros 
> can.

I had no intension whatsoever to remove macros. For most uses I think 
they are superior to Java tags.

> 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").

Agree with that. We had some discussions about life cycle and contracts 
for tags and agreed about requiring them to be thread safe so that all 
setup work can be done at compile time. They would work in the same way 
the tags you have implemented. So I think they should get the same 

> 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.

AFAIU that comment was based on some missunderstanding about where we 
were heading and about what macros can do. No plans in such a direction 
anymore AFAIK. Macros and import is of course much better.

> 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.

Yes, selection, iteration over a sequence and also some mechanism for 
recursive application (e.g. macros) for handling tree structured data, 
is necessary if the template language should be usable for presenting 
business data. Believing that we can do without them is ungrounded 
wishfull thinking. Being able to perform side effecs in the model is 
however something completely different. Allowing that makes it more 
similar to a real programming language.

> The funniest post of all was this 
> I mean, give me break. That is just plain silly.
> I never realized inner classes were so _scary_.

They are not scary per se. It is the amount of them and the size of the 
file that creates the impression that it is hard to understand JXTG. Now 
after having studied the code in some detail I have realized that it is 
quite well structured and has a efficient and reasonable design. But it 
requires some work to get to that point.

Also a problem with having a large class with lots of inner classes with 
package scoped variables is that they, in principle, can communicate in 
all kinds of unstructured ways through the global variables (from the 
outer class) and from the member variables in the inner classes. This 
also complicates understanding as it is not enough to look at the 
interfaces, you must check the bodies of all methods for understanding 
the communication patterns.

Now Leszek's refactoring showed that the communication through global 
variable is rather limited.

> (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.)

We have blocks now and, a whish to be able to reuse a number of 
mechanisms from JXTG in other places, so now it makes sense to breake it 
up in smaller parts and to formalize some contracts within it.

I think you shouln't see this work as some kind of bad critique against 
your work, rather the opposit. We wouldn't spend a lot of energy in 
using your work as base for future templating stuff in Cocoon otherwise.

Now if you don't take part in this work it will probably not be like you 
would like it in every detail, but we need to adapt the code for new 
requirements and you said earlier that you retired from the project.

I would of course appreciate if you take part in our work.

>  If you insist on
> making them external classes please make sure they aren't public.

I don't follow you here, what is the problem with making them public?


View raw message