Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <32863.10.0.0.5.1102175807.squirrel@www.agssa.net>
In-Reply-To: <41B1B478.1080608@nada.kth.se>
References: <41B0D196.5080707@apache.org> <41B0DC0A.2030308@umn.edu>
    <33059.10.0.0.5.1102112890.squirrel@www.agssa.net>
    <41B1B478.1080608@nada.kth.se>
Date: Sat, 4 Dec 2004 09:56:47 -0600 (CST)
Subject: Re: [RT] do me a favor, don't call them taglibs
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-6.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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.

WDYT?

Best Regards,

Antonio Gallardo.