Helma Logo
main list history
previous version  overview  next version

Version 23 by Lehni on 04. January 2006, 04:43

== Spec ==

# Macros in skins are delimited by (% %).
# Macros can contain both named and unnamed parameters, in any combination (see Notes for implementation details).
# Named parameters are denoted as name=value, unnamed parameters are denoted as value.
# For string parameter values, single or double quotes are optional unless the value contains whitespace characters.
# Macro parameter values wrapped in ( ) are interpreted as nested macros.
# Macro parameter values wrappedn in {{ }} are interpreted as nested skins.
# Skins and macros are both implemented as plain JS objects.
# Nested skins and macros are passed to macros as skin and macro objects, respectively. In other words, macro evaluation and skin rendering is up to the containing macro.
# Standard macros such as if/else, foreach, equals, greaterThan are implemented as plain macros in JS.

== Notes ==

* My original intention was to use * instead of % for top level macro delimiters, but Gobi would interpret these as Wiki links. Anyway, I haven't committed myself to any choice of delimiter sequences, I just think my current proposal looks pretty sane and implementable to me. I do think this is an essential question.
* Even though it doesn't look that way, this proposal provides easy backwards compatibility with old style model domain macro syntax and conventions. I'll show how when I talk further about JS implementation.

Macro parameters are passed in a way that allows sequential value lookup, sequential name lookup and named lookup:

    var param = {
      values: [],
      names: [],
      byName: {}

== Examples ==

==== Simple login info/form

  if (user) {{
    <div>Logged in as (% user.name %)</div>
  }} else {{
    <form action="(% loginUrl %)">
      <td>Name</td><td><input name="name"></td>
      <td>Password</td><td><input type="password" name="password"></td>

==== Story with comments

Variant 1, using multiple skin/macro nesting:

<h1>(% story.title %)</h1>
<div>(% story.text %)</div>
  if (story.hasComments) {{
  (% foreach comment in (story.comments)
      <td>(% encode(comment.title) %)</td>
      <td>(% encode(comment.text) %)</td>

Variant 2, using prefix and suffix parameters to avoid nesting:

<h1>(% story.title %)</h1>
<div>(% story.text %)</div>
  foreach comment in (story.comments)
      <td>(% encode(comment.title) %)</td>
      <td>(% encode(comment.text) %)</td>
  prefix=<table> suffix=</table>

== Comments ==

==== Juerg Lehni

I find this proposal somehow unclear and not so straight forward, but maybe I'm just missunderstanding it. Here are some remarks:

<div class="reply">Replies in red by hannes. BTW, the css class for red indented text is "reply".</div>

* You are using commment.title, comment.text, user.name in your examples, and I'm not sure if these are simply properties of these objects or if they're actually defined as macros. I would assume the second is the case. <div class="reply">I would think in these cases that these are just plain properties. I think direct property access will be enhanced in Helma 2 from what is possible in Helma 1. But strictly speaking, this is not part of this proposal, which is about template/skin syntax.</div>
* "Macro parameter values wrapped in ( ) are interpreted as nested macros": Again: I assume you're talking about parameters such as comment.title. But what if I'd want to call encode with a constant string as parameter? <div class="reply">For a constant string, you'd just write it as-is, or wrapped in quotes (see point 4 in the spec)</div>
* Macros / Nested Skins: I understand that you want to try to avoid the mixing code / content scenario, but i somehow find the current proposal even more confusing than the previously discussed nesting of "code" and content blocks. The problem is that there are two kinds of open / close "tags" now ( "(%", "{{" ), and it seems to become rather hard to keep the overview. <div class="reply">I think this is the better approach. Most template engines just have tags to mark the beginning and ending of code sections, but they have no way of marking embedded skins and code. Having real embedded skins and macros is much preferable to me.</div>
* If foreach is implemented as a JavaScript macro, how could this notation be possible: (% foreach comment in (story.comments)?<div class="reply"><tt>foreach</tt> is the macro name, <tt>comment</tt> and <tt>in</tt> are both constant unnamed string parameters, <tt>story.comments</tt> is a embedded macro.</div>
* Likewise, how is it possible to have two macros with each a nested skin inside one macro block, and the macros' execution depending on each other. That would be the case with a construct like (% if {{ }} else {{ }}  %)<div class="reply"><tt>if</tt> is the macro name, the first and third parameters are nested skins, the second parameter is constant string "else".</div>
* prefix / suffix: While it's nice to have this in the foreach example because it removes the need for checking for hasComments, I think it just increases complexity and makes the result harder to read.<div class="reply">I think it does in some cases, but it makes things simpler in others. I do think it's a good thing to keep, not just because it's part of Helma's heritage.</div>

<div class="reply">Reply by Juerg:

I now understand your porposal properly. It's a nice idea to use unnamed parameters and subskins as equal parts in order to create a pseudo-code like syntax.
But there are still some akward things as well:
* "foreach comment in (story.comments): comments)": The placement of the parantheses looks weird. It makes technically sense, but it gives me a slightly hackish impression...
* the nesting of macros, subskins, and macros within the subskins is complicated. I think it will tend to be hard to read, especially without a highlighting editor for this template format.
* The double curly-braces give the feeling of some kind of code-block following. And in other template engines it is used just for the opposite, to print out a value (e.g. in django. The page about templates is worth a look: http://www*http://www.djangoproject.com/documentation/templates/ )com/documentation/templates/*).