Helma Logo
main list history
previous version  overview  next version

Version 17 by hannes on 04. April 2007, 14:51

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 pipes/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/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(argformat_filter(date, param)
    return argdate.format();
  }

You can use regular expressions directly as filters:

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

=== Deep/Reach-through macro invocation ===

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

  <% page.author.name %>

Since deep macro invocation poses a potential security risk for applications that support skins by untrusted users, this feature The handler object path is disabled resolved by default calling method <code>getMacroHandler(name)</code> successively on each handler path element. The method takes the next path element as string and must be enabled with is supposed to return the allowDeepMacros setting in appnext path element, similar to getChildElement(name) for request path resolution.properties or server.properties file: 

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

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

Helma 1.6 allows macros as introduces features to automatically process macro attribute valuestag 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 name.

  <% 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) { ... }

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

=== New standard failmode attribute Unhandled macros ===

Helma macros support a 1.6 introduces two new standard attribute, in addition to <code>prefix</code>, <code>suffix</code>, <code>default</code> and <code>encoding</code>features for dealing with unhandled macros. 

The <code>failmode</code> attribute,first is the <code>unhandledMacro</code> callback. if definedIf this is defined (in the global scope or on the handler object, will cause error messages for failed depending on whether the macro is global or unresolved macros to be generated or suppressednot), it is invoked with the name of the unhandled macro, followed by the macro parameters. 

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

Note that <code>unhandledMacro</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).

=== 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, Security issues ===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 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. Therefore, this feauture is disabled by default and must be activated using the allowDeepMacros property.

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.

=== Known bugs ===


     removed
     added