cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: JXTemplateGenerator
Date Fri, 10 Dec 2004 23:02:11 GMT

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

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

View raw message