Re: Templating: experiments with Conal's html-to-xslt transform
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 | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
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 | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
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 smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
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
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 | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
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 | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Re: Templating: experiments with Conal's html-to-xslt transform
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[EMAIL PROTECTED]/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
smime.p7s
Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
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 smime.p7s Description: S/MIME cryptographic signature
RE: Templating: experiments with Conal's html-to-xslt transform
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
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 smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
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 smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
On Fri, 10 Dec 2004 15:04:20 +0100, Bertrand Delacretaz [EMAIL PROTECTED] 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
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
