In particular at Greenpeace, for instance, I extended ad_return_template to be "smart" about locale settings and to optionally return a custom .adp file for a particular locale if one is provided.  This means designers for various Greenpeace sites can simply modify the .adp files to change details of look and feel (though not structure to a very great degree) while all share a single Tcl script file.  The latter's kept safely in the hands of the programmers.

I don't understand the motivation here.  acs templating works very well and if I were to list 100 projects to work on to improve OpenACS, replacing it wouldn't be on the list.  Or the list of the next 100 projects.  And so on.

The ADP compiler can be extended with custom tags and you can dump Tcl code inline ("foreach") for instance.  What advantages would your templating system provide over that approach which we've rejected? (though this is how AOL writes their pages).

Now that aolserver supports tDom I would look at using XSL for the kind of templating you are talking about. The advantages would be no code (or very little), the designer would have access only to the XML document not the entire TCL namespace and it's fairly well documented. Unfortunately XSL is about as Dreamweaver (and perhaps designer) unfriendly as it gets.

The change from [set arg arg] to <tcl:set arg arg /> is easy, it can even be a compile time option (for the compiler not the scripts). However, representing the args as attributes might be a problem. The issue is the quoting rules for XML attributes conflicting with the quoting and other rules for Tcl args.

The model I am using is to allow the lexer find valid arg tokens and pass them to the parser to validate the grammer. Neither of these parts can verify the validity of the arguments (neither can the Tcl parser, arguments are opaque). I do examine the arguments a little. I verify they do not contain embeded commands, but combining two quoting schemes might confuse more than help the situation.

I looked into XSL, as others have pointed out, it is complex and unfriendly. It is also a full programming language, and could access resources based on what is contained in the XSLT. But the main issue is that it isn't apparent how the XML document would be created from the Tcl scripts, since the model with Tcl is to define variables and execute commands. You would still be stuck with the task of creating an XML document, or DOM from Tcl structures. My goal was to use the Tcl language as much as possible, and as safely as possible so that display code can be completely separated from other types of code. I also want to be able to use it in as many places as possible, like within a database or in procedures where templates might be stored in the database.

The webserver tclhttpd uses Safe-Tcl and a simple templating language. Files ending in .tml are run through subst. Unfortunately this eliminates all the important selection and iteration commands that make a templating language useful.

<tcl:foreach name="a" select="array">
      <tr>
        <td><tcl:value-of select="a(name)"></td>
        <td><tcl:value-of select="a(age)"></td>
        <td><tcl:value-of select="a(city)"></td>
      </tr>
    </tcl:foreach>

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.

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>>

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

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.

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.

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.

• Safe: I need a template language, tcl based, which is safe. By safe, I mean than a designer cannot create a template which does something bad to the system, like delete files, open sockets, access resources beyond what are needed. In practice, what can be done is determined by the controller script. This allows you to safely split design/display/view, from the model and controller. Designers or even users could provide templates without great risk to the system.

  Tcl has a few thing which make it impossible to make safe in a simple way. One problem is embeded commands, things like $a([exec rm -rf /]) look just fine to Tcl and the exec is executed first before Tcl realizes things are not good. The 'for' command is also unsafe. You can do 'for {script} {test} {script} {...}', and whatever is in the first (and third?) argument is executed. There is a way to make a safe interp using Safe Tcl, but this is unworkable in AOLserver, and cumbersome to setup. Also, Safe Tcl isn't about templating.

  This system allows a restricted set of what constitutes an argument. There cannot be unescaped '[' in an argument. Variable names must start with a letter and can only contain a limited set of chars, specifically excluding '['.

• Portable: It would be nice if you could use the template system everwhere Tcl can be used: in OpenACS, AOLserver, Tcl packages, inside a database which supports Tcl, etc. This also implies that the compiler should work on buffers as well as files. I haven't made this change yet, but it should be easy.
• Independent: the template compiler should not have to look outside of itself to figure out what to produce (or what is safe), templates compiled on one system will produce exactly the same result (tcl script) as on another system.
• Modular: each template is a complete script. If-elseif-else and foreach statements have to be complete. Commands have to at least look like valid code. The compiler will check the grammer of the template and will produce an error if the template isn't valid. This is still similar to tcl: you can't verify the runtime validity, but you will not end up with strange errors at runtime due to bad syntax.
• MVC Model: It is obvious that template systems are most useful for separating code (model/controller) from display (viewer). However, most systems allow arbitrary includes: this turns the template into the controller. In addition, if a system only works on files and cannot work in memory, you end up writing tcl code which handles the formatting/display functions. If templates can be handled as strings, and are known to be safe, you can use the MVC model everywhere, not just in the final stages of presentation. You can even use a template as a formatting tool: again safely.

As an example of usefulness (although not beauty) take a look at this photo album. This wasn't an OpenACS site but since I had a simple photos package, written for OpenACS, I decided to adapt it to an AOLserver module. The original used ATS, and didn't use the 'grid' tag, so five images would just take up five columns and extend off the page. I didn't have a grid tag, but I did have an 'if' tag which takes standard tcl expressions, so it was easy to create a grid using a template fragment as simple as:

 [if {($photos(rownum) % $cols) == 0} ]
 </tr>
 <tr>
 [/if]

One nice feature of the ATS grid tag is that you can flip the orientation. In my system you would need to create a resource to do this, but it turns out to be very efficient. I created a proc which takes a list and creates another list, with a modified order, depending on the number of columns you want in the output. Since the foreach tag takes a list of arrays, the new list just accesses the arrays in a modified order, allowing you to create the flipped orientation.

I also found that the group tag is easy to replace. However, it is slightly ugly:

[set v ""]
[foreach row $rlist]
 <tr>
[if {"$v" ne $row(a)}]
  <th colspan="6" align="left">a = $row(a)</th>
 </tr>
 <tr>
  <td>&nbsp;</td>
[else]
  <td> </td>
[/if]
[set v $row(a)]
[/foreach]

You would have one if block for each group by.

Clicking on a link - should route to the edit page of the grid view with all the values.

Trying to have the edit page of the grid view.