cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] do me a favor, don't call them taglibs
Date Sat, 04 Dec 2004 17:00:50 GMT
Antonio Gallardo wrote:
> 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.

The template stuff is all about consilidating JXTG and creating a 
framework where new research is possible.


View raw message