Helma 1.5 skin rendering is broken

The more I think about it, the more I find that skin rendering in Helma 1.5 is quite broken, and we need to make a (minor) step in Helma 1.6 to get rid of the worst of it.

Here's what I found so far:

• Macro handler lookup: handlers are looked for in the path of the HopObject the skin is being rendered on first, and only then in res.handlers. The reason for this is that at one time, it was impossible to register handlers at all (before res.handlers, the request path was used for handler lookup), so it would have been impossible to address anything outside/beyond the request path.
• Global and non-global macros: In the old days, global and non-global macros could simply be kept apart by looking at whether the macro name contained a dot character. This makes less and less sense to me, since global macros may be packed into namespaces as well, and with filters and nested macros, it is quite conceivable that people might want to address handlers directly as macro return values (e.g. to send it down a filter chain, or to send it as an argument to another macro).
• Finally, the i think the param argument to the renderSkin* methods had been deprived of its usefulness as describe in this comment. I think the param argument would be most useful if it simply was another way of directly registering stuff in res.handlers.

Proposed Changes

[Update 2007/03/30] Here are the measures I came up with after a few days of rumination:

• Add a simple syntax that allows to reference parameter handlers in macro tags: If a parameter value (or macro name?) starts with a "$", Helma will try to convert it to the value of the corresponding res.handlers property before passing it to the macro. For example, <% list page=$page %> will result in the list macro being invoked with res.handlers.page as argument, rather than the string "$page". With this we can disambiguify global macros from handler references.
• Introduce an app property to disable handler lookup in the parent path of the this-object. The goal is to enable a setup where res.handlers is the only place for macro handlers.
• Introduce an app property that allows to define namespaces for global macros and filters. The default will be null, i.e. global macros will be looked up in the global scope, while tidiness-concious apps will put global macros and filters into namespaces like helma.macros and helma.filters. It may be possible/disirable to define multiple namespaces to form a search path form global macros.

These changes would solve all problems above, except the param->res.handlers feature, which anyway is easier done in JavaScript when implementing a renderPart()/render() as proposed by Tobi.

[Update 2007/03/31] Actually, I'm not really sure about the first item (the $handler syntax). But since I have reframed the problem (from dealing with yet another conflict case to simply avoiding it by sprinkling some after-processing magic dust) I have stopped worrying. I think it's just a matter of hours/days until some really right solution pops up, maybe involving JavaScript instead of Java.

  var no_macro = function() {return "no";}
  res.handlers.global = {foo_macro: function() {return "foo";}
  res.handlers.bar_macro = function() {return "bar";}

  <% no failmode="silent" %>
  <% global.foo %>
  <% bar %>

  "foo"
  "bar"