You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2004/12/10 11:27:43 UTC
Templating: experiments with Conal's html-to-xslt transform
(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 ;-)
-Bertrand
[1] http://wiki.apache.org/cocoon/HtmlToXsltExperiments
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110246247525208&w=2
[3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110231970204971&w=2
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Christian Stocker <ch...@bitflux.ch>.
On 11.12.2004 18:37 Uhr, Gregor J. Rothfuss wrote:
> Christian Stocker wrote:
>
>> As I mentioned before (to one of stefano's posts), we did something
>> similar, but with the TAL syntax. We convert that to XSLT with XSLT
>> and then do the actual transformation with XSLT. It's the same idea as
>> yours. I like the approach, even though it's not complete yet (our
>> implementation) and we could certainly add some of your ideas.
>>
>> Here's the XSLT
>>
>> http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
>>
>> and here's simplel template
>> http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
>>
>> I don't say, our approach is better than yours, I didn't build an
>> opinion on that. But maybe we could join efforts in it. As it's a pure
>> XSLT implementation, the programming language behind doesn't really
>> matter.
>
>
> and to take this one step further, what would it take to make these
> templates editable in BXE? being able to make layout changes inside the
> lenya GUI, say, would rock.
The templates are XML, so in principle, no problem for BXE. If it's
attribute driven, even less.
What would really rock is some templating-enhanced mode. Not sure, what
that should include, but maybe some straightforward
adding-template-attributes stuff or real-time transformation to see the
actual result or Build-My-XPath wizards or whatever.
Btw, I didn't find the time to compare TAL with Conal's approach, but I
should have some time tomorrow to do that and build an opinion on my own..
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Christian Stocker wrote:
> As I mentioned before (to one of stefano's posts), we did something
> similar, but with the TAL syntax. We convert that to XSLT with XSLT and
> then do the actual transformation with XSLT. It's the same idea as
> yours. I like the approach, even though it's not complete yet (our
> implementation) and we could certainly add some of your ideas.
>
> Here's the XSLT
>
> http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
>
> and here's simplel template
> http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
>
> I don't say, our approach is better than yours, I didn't build an
> opinion on that. But maybe we could join efforts in it. As it's a pure
> XSLT implementation, the programming language behind doesn't really matter.
and to take this one step further, what would it take to make these
templates editable in BXE? being able to make layout changes inside the
lenya GUI, say, would rock.
-gregor
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Christian Stocker <ch...@bitflux.ch>.
On 13.12.2004 8:22 Uhr, Bertrand Delacretaz wrote:
> Hi Christian,
>
>> ...I don't know, which is more complicated, can't tell. But I took
>> your example and wrote it in TAL. See
>> http://wiki.bitflux.org/Templates_TAL_Example for details...
>
>
> Thanks, this looks really interesting. I'll have a closer look ASAP.
JFYI. Add just added METAL support. From my Blogpost
<http://blog.bitflux.ch/archive/added-metal-support-to-xsl-tal.html>:
***
METAL is the ZPT/TAL way of replacing parts of your template with parts
from other templates, for example for footers and headers. I implemented
basic support for that in our tal2xslt template. metal:fill-slot and
metal:define-slot are still missing, but should be doable.
***
chregu
>
> -Bertrand
>
>
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Christian,
> ...I don't know, which is more complicated, can't tell. But I took
> your example and wrote it in TAL. See
> http://wiki.bitflux.org/Templates_TAL_Example for details...
Thanks, this looks really interesting. I'll have a closer look ASAP.
-Bertrand
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Christian Stocker <ch...@bitflux.ch>.
On 10.12.2004 14:24 Uhr, Bertrand Delacretaz wrote:
> Hi Christian,
>
>> ...As I mentioned before (to one of stefano's posts), we did
>> something similar, but with the TAL syntax. We convert that to XSLT
>> with XSLT and then do the actual transformation with XSLT. It's the
>> same idea as yours. I like the approach, even though it's not
>> complete yet (our implementation) and we could certainly add some of
>> your ideas...
>
>
> Sorry that I overlooked this, I was busy at the time and forgot about
> it (and we didn't meet at the non-happening Bern dinner, too bad - our
> day will come ;-).
No problem. I'm busy most of the time, too. And the dinner was just
postponed, AFAIK ;)
>> ...http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/
>> template.tal.
>
>
> Trying to jump into the head of the "average HTML template designer",
> to me this looks more complicated to understand than the example at
> http://wiki.apache.org/cocoon/HtmlToXsltExperiments. But you're setting
> attributes and I'm not, might account for some of the differences in
> (perceived) complexity.
I don't know, which is more complicated, can't tell. But I took your
example and wrote it in TAL. See
http://wiki.bitflux.org/Templates_TAL_Example for details.
The main difference between your and my implemention looks like the
{foo/bar} syntax vs. the tal:content attribute syntax. I don't know,
which one's better. In TAL we could provide both ways (where one is just
an alias to the other). The rest is more or less just another syntax,
with the same idea.
The reason, why I took TAL as a starting point was that TAL is used
since years (AFAIK) in the Zope community and the syntax has proven to
be somehow useable. So why reinventing the wheel ;) And even if Zope
doesn't use XML as "we" do, the choosen approach for accesing
Zope-Objects was very near to the XPath syntax and an implementation
quite easy.
>
>> ...I don't say, our approach is better than yours, I didn't build an
>> opinion on that. But maybe we could join efforts in it. As it's a
>> pure XSLT implementation, the programming language behind doesn't
>> really matter...
>
>
> Right, this is purely an XSLT thing. And joining efforts is good, even
> if it's only stealing ideas back and forth. I don't think we (Cocoon
> and bitflux) necessarily need to agree on everything, the resutling
> XSLT code won't be very big anyway.
Agreed. And I already started with stealing ideas ;) I implemented the
@match idea in our TAL implementation. Very simple, but certainly "good
enough" for 95% of the use-cases.
For the another 5% I added @include support. With this you can include
external xslt-files with additional, maybe more complicated
xsl:templates. There's more information about that on the wiki page
mentioned above.
> After replying to Daniel, I think having a "declarative rules" section
> or not in the template is a key point: IMHO the "copy some elements
> with minor changes" scenario is very common, the bindings.xml use-case
> in my example shows this.
>
> How would you handle this with your syntax? For example, transforming
> an XHTML input document by adding class attributes to <table> and <p>
> elements, without knowing where they appear in the input?
<div tal:match="table">
foo bar..
</div>
like you ;) The original TAL has no concept of element matchers or
similar. Just moving around strings (and escaping or not escaping them).
This is what XSLT makes so powerfull and why I dislike all "traditional"
templating systems in general. But with the match attribute idea from
html2xslt, we can use this feature here as well. Thanks for the input ;)
> In my example you just need to add a "declarative rules" section like
> this, assuming you have an apply-templates in the main section:
>
> <div id="atl-templates">
> Note that we can add text here to explain what's happening.
> Here we add a class attribute to p's
> <div match="p">
> <p class="cool">
> <div apply-templates="node()"/>
> </p>
> </div>
>
> Add a border to tables:
> <div match="table">
> <table border="1">
> <div apply-templates="*"/>
> </table>
> </div>
> </div>
I did not use the id="atl-templates" idea. You can write your matchers
in any position you want in my approach. Adding Text-To-Explain is not
really needed here, there are other ways to do that in TAL.
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Christian,
> ...As I mentioned before (to one of stefano's posts), we did something
> similar, but with the TAL syntax. We convert that to XSLT with XSLT
> and then do the actual transformation with XSLT. It's the same idea as
> yours. I like the approach, even though it's not complete yet (our
> implementation) and we could certainly add some of your ideas...
Sorry that I overlooked this, I was busy at the time and forgot about
it (and we didn't meet at the non-happening Bern dinner, too bad - our
day will come ;-).
> ...http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/
> template.tal.
Trying to jump into the head of the "average HTML template designer",
to me this looks more complicated to understand than the example at
http://wiki.apache.org/cocoon/HtmlToXsltExperiments. But you're setting
attributes and I'm not, might account for some of the differences in
(perceived) complexity.
> ...I don't say, our approach is better than yours, I didn't build an
> opinion on that. But maybe we could join efforts in it. As it's a pure
> XSLT implementation, the programming language behind doesn't really
> matter...
Right, this is purely an XSLT thing. And joining efforts is good, even
if it's only stealing ideas back and forth. I don't think we (Cocoon
and bitflux) necessarily need to agree on everything, the resutling
XSLT code won't be very big anyway.
After replying to Daniel, I think having a "declarative rules" section
or not in the template is a key point: IMHO the "copy some elements
with minor changes" scenario is very common, the bindings.xml use-case
in my example shows this.
How would you handle this with your syntax? For example, transforming
an XHTML input document by adding class attributes to <table> and <p>
elements, without knowing where they appear in the input?
In my example you just need to add a "declarative rules" section like
this, assuming you have an apply-templates in the main section:
<div id="atl-templates">
Note that we can add text here to explain what's happening.
Here we add a class attribute to p's
<div match="p">
<p class="cool">
<div apply-templates="node()"/>
</p>
</div>
Add a border to tables:
<div match="table">
<table border="1">
<div apply-templates="*"/>
</table>
</div>
</div>
-Bertrand
[users@httpd] Re: Templating: experiments with Conal's html-to-xslt transform
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Christian Stocker wrote:
> As I mentioned before (to one of stefano's posts), we did something
> similar, but with the TAL syntax. We convert that to XSLT with XSLT and
> then do the actual transformation with XSLT. It's the same idea as
> yours. I like the approach, even though it's not complete yet (our
> implementation) and we could certainly add some of your ideas.
>
> Here's the XSLT
>
> http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
>
> and here's simplel template
> http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
>
> I don't say, our approach is better than yours, I didn't build an
> opinion on that. But maybe we could join efforts in it. As it's a pure
> XSLT implementation, the programming language behind doesn't really matter.
and to take this one step further, what would it take to make these
templates editable in BXE? being able to make layout changes inside the
lenya GUI, say, would rock.
-gregor
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Christian Stocker <ch...@bitflux.ch>.
On 10.12.2004 11:27 Uhr, 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 ;-)
As I mentioned before (to one of stefano's posts), we did something
similar, but with the TAL syntax. We convert that to XSLT with XSLT and
then do the actual transformation with XSLT. It's the same idea as
yours. I like the approach, even though it's not complete yet (our
implementation) and we could certainly add some of your ideas.
Here's the XSLT
http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
and here's simplel template
http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
I don't say, our approach is better than yours, I didn't build an
opinion on that. But maybe we could join efforts in it. As it's a pure
XSLT implementation, the programming language behind doesn't really matter.
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Christian Stocker <ch...@bitflux.ch>.
On 10.12.2004 11:27 Uhr, 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 ;-)
As I mentioned before (to one of stefano's posts), we did something
similar, but with the TAL syntax. We convert that to XSLT with XSLT and
then do the actual transformation with XSLT. It's the same idea as
yours. I like the approach, even though it's not complete yet (our
implementation) and we could certainly add some of your ideas.
Here's the XSLT
http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
and here's simplel template
http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
I don't say, our approach is better than yours, I didn't build an
opinion on that. But maybe we could join efforts in it. As it's a pure
XSLT implementation, the programming language behind doesn't really matter.
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 10 déc. 04, à 14:34, Conal Tuohy a écrit :
>> ...the "rules" section works in a
>> different way than the rest.
>>
>> WDYT?
>
> I like the idea - in fact I had the same idea myself, but without
> adding a
> special "rules" section. I'm not sure I see the point in keeping it in
> a
> special div? I think it's good to allow people to define templates
> anywhere
> in the template file ... that way you can take a "design dummy" page
> and
> simply annotate it with these attributes without having to rearrange
> it...
OTOH these "inline rules" might make the template more confusing to
said dummy if he needs to work on the page again?
My aim was to make it very clear that the rules are something special
that one must learn (a bit) about, hence the separate section, with
interspersed text a la literal programming, as the rules often need
some explanation to the template author.
Also, the separate section makes it clear that these rules can be
called in any order.
> ...Another thing it really should have is a way to declare global
> parameters,
> passed to it from the sitemap. The old stylesheet I posted the other
> day
> automatically declares parameters "id" and "random" because they were
> common
> requirements of our templates, but it would be better to have to
> declare
> them explicitly. e.g. <html template:parameters="foo bar baz">..
Right - but parameters often need default values, how about using
<meta> for them?
<meta atl:parameter="foo" atl:keep="true" content="default-value"/>
Where atl:keep means we want to keep it in the HTML output for
debugging or indexing.
> ...I've done some work (not yet finished) on a similar transform to
> jxt, but
> without any pattern-matching templates so far (they're not impossible,
> just
> not quite so easy, because jxt doesn't already have pattern-matching
> templates)...
Cool - but HTML to XSLT already looks very useful!
-Bertrand
RE: Templating: experiments with Conal's html-to-xslt transform
Posted by Conal Tuohy <co...@paradise.net.nz>.
Bertrand wrote:
> For me, the template author just wants to say "all <table> elements
> must be copied with border=1 added", but he has no idea in
> which order
> the elements will appear in the source, and shouldn't have to care.
>
> Does your for-each syntax allow this? I think it requires declarative
> rules, and if we're careful about how they are defined, they won't be
> too scary and will add a lot of power. I've put my rules in a
> separate
> div on purpose, to make it clear that the template has a
> "linear" part
> and another "rules" section, and that the "rules" section works in a
> different way than the rest.
>
> WDYT?
I like the idea - in fact I had the same idea myself, but without adding a
special "rules" section. I'm not sure I see the point in keeping it in a
special div? I think it's good to allow people to define templates anywhere
in the template file ... that way you can take a "design dummy" page and
simply annotate it with these attributes without having to rearrange it.
Another thing it really should have is a way to declare global parameters,
passed to it from the sitemap. The old stylesheet I posted the other day
automatically declares parameters "id" and "random" because they were common
requirements of our templates, but it would be better to have to declare
them explicitly. e.g. <html template:parameters="foo bar baz">
I've done some work (not yet finished) on a similar transform to jxt, but
without any pattern-matching templates so far (they're not impossible, just
not quite so easy, because jxt doesn't already have pattern-matching
templates).
Cheers
Con
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 10 déc. 04, à 13:18, Daniel Fagerstrom a écrit :
> ...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...
Sure - I was going to wait a bit for feedback though, as this is really
not specific to Cocoon, only to XSLT, so maybe some non-committers can
collaborate on the wiki before going to SVN.
> ...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...
You're right, we need to namespace the attributes, it's much cleaner.
> ...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; }}
No need to do that, the <script> element is copied verbatim when
creating the final XSLT. The wiki example works as is.
> ... <div class="content">
> <div for-each="//document/body/s1" class="s1">
> <h2>{@title}</h2>
>
> <!-- This copies paragraphs in the input: -->
> <p for-each="p"
> copy-of=".">
> Example paragraph
> </p>
Is that a rule, or does this mean that all <p> will come before the
<table> that is below?
> <table border="1">
> <tr for-each="tr" copy-attributes="@*">...
I think rules are needed, our xdocs are a good use case: they contain
some stuff that is already xhtml-compatible, that you only need to copy
with small adjustments, as in my example where I add a border on the
<table>.
For me, the template author just wants to say "all <table> elements
must be copied with border=1 added", but he has no idea in which order
the elements will appear in the source, and shouldn't have to care.
Does your for-each syntax allow this? I think it requires declarative
rules, and if we're careful about how they are defined, they won't be
too scary and will add a lot of power. I've put my rules in a separate
div on purpose, to make it clear that the template has a "linear" part
and another "rules" section, and that the "rules" section works in a
different way than the rest.
WDYT?
-Bertrand
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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:
<html>
<head>...</head>
<body>
<h1>{document/header/title}</h1>
<p class="note">The layout of this HTML page is defined
doc2html-template.xhtml</p>
<div class="content">
<div for-each="//document/body/s1" class="s1">
<h2>{@title}</h2>
<!-- This copies paragraphs in the input: -->
<p for-each="p"
copy-of=".">
Example paragraph
</p>
<table border="1">
<tr for-each="tr" copy-attributes="@*">
<td for-each="td"
copy-of=".">
Example table cell
</td>
<td ignore="true">
A second table cell to make it look nicer
</td>
</tr>
</table>
</div>
</div>
</body>
</html>
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
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Geoff Howard <ge...@gmail.com>.
On Fri, 10 Dec 2004 15:04:20 +0100, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Le 10 déc. 04, à 14:44, Upayavira a écrit :
> > ...I like this kind of approach, and am implementing a similar system
> > at the moment...
>
> Great! Let's make this a documented/mainstream part of Cocoon, it's
> cheap to do and could make a big difference in the perception of
> Cocoon.
>
> I say "perception" because all this is already possible, we're just not
> showing it well enough I think.
>
> > ...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!)..
>
> Right. Links to DW information are welcome, I've searched a bit but
http://www.macromedia.com/support/documentation/en/dreamweaver/
Notable links from that page:
- Extending Dreamweaver MX 2004
- Dreamweaver API Reference
No time to help but very enthusiastic about the idea,
Geoff
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 10 déc. 04, à 14:44, Upayavira a écrit :
> ...I like this kind of approach, and am implementing a similar system
> at the moment...
Great! Let's make this a documented/mainstream part of Cocoon, it's
cheap to do and could make a big difference in the perception of
Cocoon.
I say "perception" because all this is already possible, we're just not
showing it well enough I think.
> ...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!)..
Right. Links to DW information are welcome, I've searched a bit but
didn't find *the* reference on DW extensions.
-Bertrand
Re: Templating: experiments with Conal's html-to-xslt transform
Posted by Upayavira <uv...@upaya.co.uk>.
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