Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 45595 invoked from network); 10 Dec 2004 12:18:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Dec 2004 12:18:25 -0000 Received: (qmail 65451 invoked by uid 500); 10 Dec 2004 12:18:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 65367 invoked by uid 500); 10 Dec 2004 12:18:17 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 65338 invoked by uid 99); 10 Dec 2004 12:18:17 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 10 Dec 2004 04:18:15 -0800 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from nada.kth.se (cvap80.nada.kth.se [130.237.218.93]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11/8.12.11) with ESMTP id iBACI8ZM017284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Dec 2004 13:18:12 +0100 (MET) Message-ID: <41B99400.1020701@nada.kth.se> Date: Fri, 10 Dec 2004 13:18:08 +0100 From: Daniel Fagerstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: sv, en-us 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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? Looks nice to me. I would sugest that you put the xslt with some working examples in the samples directory in the template block. So it becomes easier to experiment with and enhance. I think that puting a name space on the attribute directives is a must. It makes it much easier to see what is code and what is data at a glance. Also it cooperates much better with a strict XHTML scheme. I have not tested how it work or read the XSLT in detail, but I wonder about the CSS rules in the style section, will not the XSLT try to expand their bodies? You could use the same escaping as in XSLT attributes: body {{ font-family: Georgia,sans-serif; }} > 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. Might be, but I think we can increase the percentage in your example by being a little bit more procedural and use "if" and "for-each" rather than rule based style. The rules could be considered as example output from a WYSIWYG perspective. By leting "if", "for-each", etc act on their embeding element instead of its context you also makes it easier to avoid rule based style. What about: ...

{document/header/title}

The layout of this HTML page is defined doc2html-template.xhtml

{@title}

Example paragraph

Example table cell A second table cell to make it look nicer
I didn't know what the sorce element does, so I skiped it. The copy directives replaces the content of its element which makes it possible to put dummy content in the elements that only are used for wysiwyg. When I use several directives they are supposed to be evaluated in the order they apear, (I have explained in other posts why I think this is a really bad idea so I will not repeat my arguments here). /Daniel