Helma Logo
main list history
previous version  overview  next version

Version 2 by hannes on 25. March 2007, 14:01

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.
* 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|http://dev<a href="http://dev.helma.org/wiki/Handler+for+rendered+skins/#$cmt1669*org/wiki/Handler+for+rendered+skins/#$cmt1669">this comment</a>. I think the param argument would be most useful if it simply was another way of directly registering stuff in res.handlers.

What all this boils down to is to simplify macro handler lookup in Helma 1.6 a fair bit, dropping the path lookup, dropping maybe the global lookup but allowing but in any case allowing objects in res.handlers to be acessed directly in macros, and providing a switch for Helma 1.5-compatible skins to disable all this and doing it the old way. What do you think?

     removed
     added