Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <41B58384.8080104@nada.kth.se>
References: <41B0D196.5080707@apache.org> <41B1B208.2080809@nada.kth.se>
 <41B509FB.8070408@reverycodes.com> <41B58384.8080104@nada.kth.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B2DCF6FB-487E-11D9-952A-000393B3DE96@hard-bop.com>
Content-Transfer-Encoding: 7bit
From: Glen Ezkovich <glen@hard-bop.com>
Subject: Re: [Templates] Summary and Voting aspects (was: [RT] Attribute
 Driven Templates)
Date: Tue, 7 Dec 2004 12:34:58 -0600
To: dev@cocoon.apache.org


On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote:

>
> Refactoring JXTG
> ================

I think everything starts here. Once this gets refactored the 
opportunities for further development should become apparent. There is 
nothing terribly wrong with JXTG, except that it is a monolithic class 
with monolithic methods.

>
> For 1), the back compabillity preserving refactoring of JXTG. I cannot 
> see any need for voting about this. Either it gains community support 
> in terms of that people joins in design, implementation and testing, 
> or it don't. And in that case we just remove it. Then if the new 
> refactored implementation should replace the current one and get 
> "oficial status", thats certainly something to vote about. Also if we 
> develop some new interfaces e.g. for ELs or formaters that we feel 
> that should be made part of core, it will also be something that 
> should be handled by proposals and votes.
>
> I can assure you that I have no urge to implement everything myself at 
> all (as some of you might have noticed I enjoy design descussions and 
> proposals more than implementing stuff ;) ),

You mean some people actually LIKE to implement stuff? ;-)

>  I will continue to strive for community involvment. And I will write 
> a proposal about how to continue the refactoring as soon as I find 
> time.


>
> Next Generation JXTG
> ====================
>
> This is about how we should continue our development of the template 
> language beyond JXTG 1.0. It is purely at the RT stage, no concrete 
> design proposals yet. Later there might be proposals in form of 
> documents or proof of concept implementations. But that is a later 
> question.

And an interesting discussion. I think once people look at the 
refactored JXTG and have an itch to scratch you will see a few attempts 
at expression language development.


>
> Attribute Driven Templating
> ===========================
>
> This is ongoing discussions. My hope is that we can design the 
> template engine in such a way that the synatx handling part is 
> plugable so that attribute and tag driven templates (JXTG) can 
> coexist, (although not in the same document ;) ).

I'm guessing that after refactoring JXTG you will see that this is 
easily doable. I'm only guessing because I have only taken a brief look 
at JXTG's code, but one of the goals of refactoring is to organize the 
code properly.

>  But that is a technical quiestion IMO. Anyway, we need to discuss the 
> consequences of dirrerent syntaxes a little bit more before 
> implementing anything.

You mean defining the language. No one wants to implement. ;-)


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