cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: JXTemplateGenerator
Date Fri, 10 Dec 2004 17:23:41 GMT
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
>
>


Mime
View raw message