Forum OpenACS Development: Re: new templating model: ideas, questions

Collapse
Posted by Tom Jackson on

Thanks for both of your input so far. I think there is some value in making this look XML/XSL like. There are some issues.

  • Attributes don't have to be in any order, in tcl order is required. Would that confuse users? The template is essentially a shorthand for a tcl script.
  • Quoting for tcl, then for XML will likely be very confusing in some cases.
  • In Tcl you have variables which look like '$a', '$a(b)', '$a($b), and then braced ${a}, etc. For instance, ATS doesn't support the '$a($b)' form, which is one reason I don't want to copy the @a.b@ syntax. Lexing would become much more involved at that point.
  • How do you include variable values inside other tags? In my original post I built up a select list, which inside the option tags were included the value and the selected variables. What does that look like in XSL?

I played around with Dreamweaver, and it does work with unnamed attributes, but it is confused a little by them. You can't edit them in the side panels. The main problem with attributes will be untangling the double quote, single quote confusion.

Collapse
Posted by Andrei Popov on
How do you include variable values inside other tags? In my original post I built up a select list, which inside the option tags were included the value and the selected variables. What does that look like in XSL?

This would be a bit tricky, I agree. Our current

  <body<multiple name=attribute> @attribute.key@="@attribute.value@"</multiple>>
is very unXML-like :)

If you were doing actual XSLT, you'd probably do something like:

  <xsl:text>&lt;a</xsl:text>
  <xsl:attribute name="href">
    <xsl:value-of select="$foo" />
  </xsl:attribute>
  <xsl:text>&gt;</xsl:text>
    foo
  <xsl:text>&lt;/a&gt;</xsl:text>

which is ugly :)

There's gotta be an easier/nicer way...

Probably what we need is:

  <tcl:with-tag name="a">
    <tcl:attribute name="href" select="$foo" />
    <tcl:attribute name="title" select="$bar" />
    <tcl:text>$baz</tcl:text>
  </tcl:with-tag>

Which sort of says: "here's an HTML tag 'a'; please create it with attributes href='$foo', title='$bar' and put text $baz within it

Collapse
Posted by Andrei Popov on
And as far as your example is concerned, maybe something along these lines:

<form action="go" method="post">
  <select name="test">
    <tcl:foreach bindlist="value description selected" array="$select">
      <tcl:with-tag name="option"
        <tcl:attribute name="value" select="$value"/>
        <tcl:attribute name="selected" select="$selected"/>
        <tcl:text>$description</tcl:text>
      </tcl:with-tag>
    </tcl:foreach>
  </select>
</form>

Note that this is not real XSL, it only looks sort of like that.

Collapse
Posted by Tom Jackson on

It seems quite bizarre that the XSL can have valid '$var's in their tags and html cannot. One thing I like the XMLish tag for, WRT the set proc is the possible usage of something like <tcl:set var />, which would be like [set var], instead of setting a variable, it would return the value of, in this case, 'var'.

I'm pretty sure I'm not going to rewrite HTML tags as part of a solution to this. That seems not helpful for designers or developers.

In the example given, I wonder how the selected attribute works, since it is just the text 'selected' inside the option tag?

I've verified this scanner/parser will work with UTF-8, for now except for '\0', which I am working on.

Collapse
Posted by Andrei Popov on

Tom,

As I said before -- whatever you see above is not real XSL. For one thing, when transforming an XML doc one does not need to handle situations of foreach {foo bar baz} $select nature, since you always look only at a foo or at a bar or at baz (as elements) and never at all of them together — you are following through the branch trees, pretty much one at a time.

My point was not in saying "Let's just use XSL/XSLT as templating basis" but rather "Look, templating language *can* be made valid XML and that without (much) sacrifice of readability"

Whether a '$var' or a 'var' should be used in the examples (and I think I was not very consistent in that usage) — this needs to be looked at and decided. You can pretty much have whatever you want in quotes, just as well as within a CDATA in XML. It would be Templating System's parser task to actualy decide upon what needs to be done with a particular '$var'. This could be made more Tcl-like (as in [set foo "bar"] as opposed to Perl's $foo="bar") or less.

Oh, and if we wanted to really use XSL, I think we could just use tDOM to do the transformation.

Collapse
Posted by Tom Jackson on

Well I've looked more into Dreamweaver and found that it is very easy to add new tag types. I think I can come up with a compromise that will allow easy usage in Dreamweaver and allow my compiler to easily identify valid code.

It turns out that in Dreamweaver, if you want to include code escapes inside attributes, you really need to use what they call an empty tag. For example, jsp/asp tags: <% %>, there is no ending tag.

So at the moment, I'm considering the following examples as equivalent:

[if $x]           [%if $x %]
[elseif {a==$b}]  [%elseif {a==$b} %]
[else]            [%else%]
[/if]             [%/if%]
[set a b/]        [%set a b /%] 
[set a/]          [%set a%] or [%= a /%] (ret value of a)
[foreach a $b]    [%foreach a $b %]
[/foreach]        [%/foreach%]
[resource text "header" ${title} /] ...

The templating language parser is helped by different ending tokens for tags like set and resource, thus the ending /] or /%] for those tags.

Collapse
Posted by Andrei Popov on
Wouldn't it make code a bit unreadable?  Also, why not then just using ADP as it was designed -- embeding code into your pages?  You'd get the <% %> pair for free then :))
Collapse
Posted by Tom Jackson on

Umm, it isn't adp! Only a few processing commands will be available, and command arguments and variables cannot contain embeded commands, and adp, requires AOLserver...First I have to satisfy the goals outlined above.