Hi Chris: Thanks for sending this mail. It explains a lot about JXTG design decisions and make things clear. Please do me a fabor, try to stay a little bit more on the list while the topic is discussed. I (and others) will be glad to hear your comments about this topic. :-D
Best Regards, Antonio Gallardo On Vie, 10 de Diciembre de 2004, 10:29, Christopher Oliver dijo: > 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 > >
