Helma Logo
main list history
previous version  overview  next version

Version 21 by hannes on 02. May 2007, 15:35

Helma 1.6 contains a number of Skin/Macro enhancements that aim to make Helma's rendering infrastructure more flexible and powerful.

=== Subskins ===

It is now possible to have multiple skins in one skin resource. Subskins are delimited using a <code><% #subname %></code> tag.

  main skin body
  <% #subskin1 %>
  subskin 1 body
  <% #subskin2 %>
  subskin 2 body

Subskins can be referenced from the outside as "skinname#subname". While a skin or subskin is being rendered (i.e. from macros contained in that skin), it is possible to reference other local subskins just using "#subname". Skin objects also *provide a getSubskin() method|http://helma.zumbrunn.net/reference/Skin.html*.

  renderSkin("mainskin");
  renderSkin("mainskin#subskin1");
  renderSkin(skin.getSubskin("subskin2"));

=== Macro filters ===

Helme 1.6 introduces a new filter feature to further process macro output.

  <% text | truncate max="300" | uppercase %>

Filter functions must have a _filter suffix and get two arguments: the return value of the previous macro or filter in the chain, and a parameter object with the attributs in the filter tag. They are expected to return the filtered macro output. Macro and filter return values are converted to string only at the end of the chain. It is therefore possible to pass other objects between macros and filters:

  <% now | format %>

  function now_macro(param) {
    return new Date();
  }
  
  function format_filter(date, param) {
    return date.format();
  }

You can use regular expressions directly as filters:

  var regexp_filter = new RegExp("\\w*");

=== Deep macros ===

Helma 1.6 allows macros to be invoked over several property path links.

  <% page.author.name %>

The handler object path is resolved by calling method <code>getMacroHandler(name)</code> successively on each handler path element. The method takes the next path element as string and is supposed to return the next path element, similar to getChildElement(name) for request path resolution.

For untyped JavaScript objects, macro path resolution also works in an autmatic way by following object properties. For prototyped HopObjects, this mechanism is disabled because of security considerations.

=== Processed parameters and nested Nested Macros ===

Helma 1.6 introduces features to automatically process supports nested macros as macro tag parameters before passing them to the macro function. If a macro parameter is wrapped as <code>$[name]</code>, the value is replaced with the object registered in <code>res.handlers</code> with that namevalues.

  <% page.image linkto=$[handlerName] %>

If a macro paramter is wrapped as <code>$(...)</code>, it is passed to a callback <code>app.processMacroParameter</code>. The callback takes the unprocessed parameter value as argument and returns the processed value.

  app.processMacroParameter = function(value) {
    if (value == "header")
      return "<h1>Page List</h1>";
  }

  <% page.list prefix=$(header) %>

Helma 1.6 also allows macros as macro parameter values.

  <% page.link content=<% messages.storylink %> %>

The main reasons to reject this over the years have been that this is ugly, and that it results in unreadable skins. But then, isn't recursion one of the coolest concepts in programming? If you think it's ugly, just don't use it. Otherwise, it may save you a handsome amount of macro writing.

=== Positional macro parameters ===

In addition to named parameters, macro functions can now be invoked with positional parameters. If the attribute name and equals sign is omitted from an parameter, it is interpreted as positional parameter. Positional parameters are passed to macro and filter functions after the parameter object containing any named parameters.

  <% image "dancer.gif" alt="Helma dancing her feet off" %>
  
  function image_macro(param, imageName) { ... }

=== Unhandled macros ===

Helma 1.6 introduces two new features for dealing with unhandled macros.

The first is the <code>onUnhandledMacro</code> callback. If this is defined (in the global scope or on the handler object, depending on whether the macro is global or not), it is invoked with the name of the unhandled macro, followed by the macro parameters.

  function onUnhandledMacro(name, param) {
      if (name == "dynamacro") {
          // actually do something useful
      } else {
          return "oops, unhandled macro " + name;
      }
  }

Note that <code>onUnhandledMacro</code> is only invoked if Helma was actually able to resolve the handler object, i.e. everything up to the actual macro name.

If a macro is not defined, and no <code>undefinedMacro</code> method is defined on the handler object, the generation of an error message can be controlled using the <code>failmode</code> attribute. If defined, it will cause error messages for failed or unresolved macros to be generated or suppressed.

  <% failLoudly failmode="verbose" %>
  <% failQuitely failmode="silent" %>

The default value is silent for request/response/session/param handlers, and verbose for app object handlers (mimicking implicit Helma 1.5 behaviour).

=== Namespaces for global macros ===

It is now possible to use global macros that are defined in a namespace as opposed to the global scope itself.

  app.globalMacroPath = ["myapp.macros", "helma.macros", ""];

Helma will loop through the namespaces defined in app.globalMacroPath until it finds the macro or filter it is looking for.

=== Fix quoted parameter parsing ===

In Helma 1.5 and earlier, a "%>" sequence was interpreted as macro end tag even if it was contained in a quoted parameter string. Helma 1.6 fixes this, making it possible to pass strings containing macro tags as parameter values to be rendered as skin by the macro function.

=== Compatibility and Security issues ===

All the changes and new features in Helma 1.6 skins are backwards compatible with Helma 1.5.

The one know security implication introduced by the new features is with deep/reach-through macro invocation and untrusted skin authors, since it allows skin authors to reach objects that may not be meant to be reached. This is why automatic property walkthrough is disabled for prototyped HopObjects.

The other new features should not affect security, since it just allows to call macros that were already callable before. The skin sandboxing feature hasn't changed and works the same as before. Macro filters are currently not affected by the sandbox.



     removed
     added