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)
Message-ID: <41B9A823.2050703@upaya.co.uk>
Date: Fri, 10 Dec 2004 13:44:03 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Templating: experiments with Conal's html-to-xslt transform
References: <210CC1D1-4A96-11D9-8BD5-000A95AF004E@apache.org>
In-Reply-To: <210CC1D1-4A96-11D9-8BD5-000A95AF004E@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Bertrand Delacretaz wrote:

> (ccing users@ as I'm sure many subscribers there could contribute to 
> this experiment as well, please discuss on dev@)
>
> I've been playing [1] with Conal Tuohy's transform [2], to generate 
> XSLT transforms based on simple attribute-based templates (HTML in 
> this case, could be whatever) and I like it very much.
>
> Converting attribute-based templates to XSLT instead of processing 
> them directly is fairly easy to implement, easy to use for the 
> template writer yet powerful by giving access, when needed, to all 
> XSLT constructs. And the syntax of attributes like for-each or 
> apply-templates *is* XSLT, so Bob can ask Alice for help when needed 
> ([3]).
>
> There's more info, including source code, on the wiki [1]. Feel free 
> to use this page as a poor man's source code control system for 
> improving this, if people like it we might want to include this our 
> distribution?
>
> Compared to Conal's version, the current version allows "element 
> templates" to be defined in the HTML template, they are similar to 
> XSLT templates but much easier to write. I think this adds a lot of 
> power while allowing the template to remain concise and modular, and 
> "fairly" editable in visual tools. There has to be a compromise 
> somewhere I think, converting XML data to HTML or another format *is* 
> programming at some stage, the "100% visual" paradigm does not work 
> for this in today's world IMHO.
>
> Comments/opinions/enhancements/flames are welcome (well, maybe not 
> flames but if you think this sucks I'm all ears ;-)

I like this kind of approach, and am implementing a similar system at 
the moment.

If we are fixated upon Dreamweaver, then we should work out how 
Dreamweaver extensions work, so that we can, with a bit of HTML and some 
Javascript, allow GUI access to the various elements we add into the 
page. This is, in effect, all that is done to give access to ASP, PHP, 
JSP, etc, in Dreamweaver, so I don't see why we couldn't do the same for 
some Cocoon markup (other than lack of interest!)

Regards, Upayavira