On Sab, 4 de Diciembre de 2004, 6:58, Daniel Fagerstrom dijo:Antonio Gallardo wrote: That is the main idea with the template initiative. Then we happened to use a word for describing the mechanism of breaking out the template tag implementations to separate files, that suddenly made every one upset.
One could break up JXTG by writing detailed test cases for JXTG and refactor in controlled steps to something more managable. But it didn't seem like anybody found that solution attractive.
I'll sugest that we see what the templating discussion leads and base further work on that.
I agree. Anyway, we (in Cocoon) have a current user base using JXTG that we cannot forget.
Definitively not. As I said the template initiative is about re-implementing JXTG in such a way that it is easier to understand and maintain. And also easier to reuse stuff that is needed in other parts of Cocoon.
If is necesary, I can do that. Some months ago, I spend a week understanding how the JXTG works. While I don't consider myself an expert. I thing we can make the life easier to others by breaking it down.
When we discussed templateing stuff it didn't seem like anybody feeled like refactoring JXTG, so we went for reimplementation of at least the script and compiler stuff. Then it was at least my intension to reuse as much code from JXTG as possible.
But if you feel like refactoring JXTG, we can certaninly work in parallell. Especially if we work fro different "directions" and keep the work sycnced so that we avoid doing the same thing twice.
If you would like to factor out the parts that build the context objects for Jexl and JXPath respectively, it would be excelent. Especially if you combine it with Carstens work in that area: o.a.c.environment.TemplateObjectModelHelper in scratchpad. If not anybody is against it I would sugest to move that component to core Cocoon so that JXTG can be refactored without needing to have two instances of it.
Handling both JXPath and Jexl expreesion through a common interface would also be nice. Basing JXTG on an abstract class that handles caching of the compiled script based on both the script source and sources to included scripts would also be good.
Factoring out the tags is not worthwhile right now IMO. Each tag has code in three different areas: In a special class for the tag, in the compiler class, and in the execute method. Maybe you could try to gather all code for each tag in the tag class. But I would sugest that we take care of this part in the template stuff instead.
I saw some problems on the user list that I guess can be easily fixed in the current implementation. BTW, I also saw the current implementation has some broken parts that need to be fixed again.
I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must.
WDYT?
The template stuff is all about consilidating JXTG and creating a framework where new research is possible.
/Daniel
