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




Reply via email to