cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [RT] do me a favor, don't call them taglibs
Date Sat, 04 Dec 2004 15:56:47 GMT
On Sab, 4 de Diciembre de 2004, 6:58, Daniel Fagerstrom dijo:
> Antonio Gallardo wrote:
>> On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo:
>>>Stefano Mazzocchi wrote:
>>>>All I ask from a template language:
>>>> 1) something that HTML designers can edit with Dreamweaver
>>>> 2) something that doesn't use namespaced tags to identify dynamic
>>>>scopes (clashes with #1)
>>>> 3) something that doesn't use the name taglib
>>>>That's pretty much all you have to do to make me happy.
>>>I believe I was responsible for originally "starting" the discussion
>>>about fixing JXTG 2, so I feel like I should probably respond.
>>>JXTG works just fine.  I just didn't want to be freaked out looking at
>>>the source.  At a minimum, having JXTG refactored, keeping the exact
>>>same functionality, and my mind would be put at ease.
>> I can try to break the original JXTG in more classes. I mean in
>> separated
>> files.
>> WDYT?
>> Best Regards,
>> Antonio Gallardo.
> 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. 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.
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.


Best Regards,

Antonio Gallardo.

View raw message