JXTemplateGenerator

[Christopher Oliver <re...@verizon.net>]

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

Re: JXTemplateGenerator

[Tony Collen <co...@umn.edu>]

(I had originally done the "write the nasty email, then delete it and 
write it again" trick.  Let's see if it works:)

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.

You should show up a little more often... you know, be a little more 
sociable.

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

(Background: It's my part of personality to become easily insulted, 
and for some reason I was initially insulted by this, but I'm not any 
mroe.  This is what caused me to have to rewrite this email a couple 
times.)

I'll admit:  I am scared by that metric shitton of code.  I'm not 
afraid to say it, either; I'm an amateur when it comes to programming. 
  But there was something else that bugged me about all that code:

I wanted to make sure the JXTG didn't suffer from the dreaded "one man 
show" syndrome.  The nice thing is that I think because of the JXTG 
discussion, we've been able to avoid it.

I wanted to make sure more than just one person knew what was going on 
with the code.  Again, because of the JXTG refactoring that's 
happening, this is no longer true as well.

I wanted to make sure that we didn't end up tossing JXT in favor or 
something new.  The JXTG plays an essential role in the "power triad," 
and dumping it would not be a good thing.  JTXG is here to stay.

I appreciate you showing up for some disussion on the issues, and I'm 
sure much of the list appreciates it too.  However, IMNSHO, before *I* 
take you seriously, you're going to have drop the sarcastic tone of 
your messages and be willing cooperate.  Please realize that not 
everyone is a super programmer.

If you're willing to hang out and chill, by all means, please stick 
around for a bit. I'm sure that people are more than willing to listen 
if you have some input to the JXTG refactoring that's happening.

I can't speak for anyone else on the list, but a helpful and 
cooperative message will get you further with your cause, at least 
with me.


Respectfully,

Tony

Re: JXTemplateGenerator

[Antonio Gallardo <ag...@agssa.net>]

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

Re: JXTemplateGenerator

[Glen Ezkovich <gl...@hard-bop.com>]

On Dec 10, 2004, at 10:29 AM, Christopher Oliver wrote:

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

I think this was me, and while we use <jx:import> and macros it did not 
occur to me to use them to solve the problem of the ever evolving site 
design. Admittedly we could have done this. And I may have overstated 
my point. You are right it is a ridiculous notion that you MUST use 
pipelines and XSLT to get reusability.  What is not ridiculous is to 
suggest that you can get greater reusability by using pipelines and 
XSLT given that your site does not use JXTG exclusively.

The sites pages came from many types of sources. We used JXTG for only 
a portion of them. Many of the page elements they used were already 
defined in XSLT. We could have created macros but that would have been 
recreating the wheel. While stating that you have to modify all your 
templates when your site design changes was too strong, in our case it 
was a more flexible solution to just use an XML template XSLT. I like 
this approach and encourage others to try but they should do what works 
best for their problem.

Regardless of how i use it I think JXTG is a wonderful tool with a 
great deal of flexibility. I don't think the effort to refactor and 
extend it is being done with anything other then love and respect.

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

Makes good sense. Remember that refactoring is useful for 
understanding. The desire for refactoring derives from people looking 
at the code and not understanding its organization and what is going 
on.  Hopefully it is not fear of inner classes. ;-) Now anonymous 
classes those give me the shivers.


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

Re: JXTemplateGenerator

[Bertrand Delacretaz <bd...@apache.org>]

Le 10 déc. 04, à 17:29, Christopher Oliver a écrit :

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

Can't swallow this one without reacting, sorry - wrong tone, and there 
is a general consensus that JXTG needs refactoring, I find it very 
unfair of you to pick on Tony specifically.

Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.

You've been quiet for a while, people are willing to take over to 
ensure JXTG's future (because it's a great tool, we *are* thankful to 
you for this), they're doing their best and we're starting to see good 
things coming out of this.

So please respect their work - as much as we respect you and your work.

-Bertrand

Re: JXTemplateGenerator

[Daniel Fagerstrom <da...@nada.kth.se>]

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

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

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?

/Daniel