Helma Logo
main list history

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:

Proposed Changes

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

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.

Comments

#1 by tobi at 2007/03/26 19:52

Hannes, I still don't get the picture of the three findings you describe. Please elaborate a bit:

  • What's the actual point in the first one? What is broken with the macro handler lookup, how should it be fixed?
  • Should there be a "global" handler to generalize the dot-syntax in macros? (Ie. <% global.myMacro %> instead of <% myMacro %>)
  • How do you think the param argument should be used to register stuff in res.handlers? How should that work?

Maybe you could also give some examples to illustrate what you mean.

#2 by hannes at 2007/03/26 20:15

What's the actual point in the first one? What is broken with the macro handler lookup, how should it be fixed?

Current handler lookup sequence is: 1) thisObject 2) thisObject path 3) res.handlers. I think step 2) should be dropped.

Should there be a "global" handler to generalize the dot-syntax in macros?

That's not what I was proposing, if that's your question. So far I was considering two options: dropping the global scope as macro namespace (requiring global macros to be registered in res.handlers), and allowing full, "deep" access to global macros in namespaces. In any case, I think this might be more important for non-global macros, which may then look like previously global macros, too (i.e. the handler is the macro).

How do you think the param argument should be used to register stuff in res.handlers? How should that work?

The following call would result in res.handlers.bar == barHandler for the time the renderSkin method was running:

renderSkin("foo", { bar: barHandler });

#3 by tobi at 2007/03/26 20:35

Okay, I think I got the first and the third parts but still struggling with understanding the second one:

How would I register a global macro in res.handlers? I am used to register handlers in there, just as the name indicates...

(Although I believe to understand that you want to achieve something like <% library.modules.macro %>, though, library being a global namespace.)

#4 by hannes at 2007/03/26 21:33

Yep, with the first option, using a global macro that is not contained within a namespace would be kind of ... difficult. The second option would make the whole global scope a macro searching field. So these options are very opposite.

I'm leaning towards option one, note the least because of security considerations. Hell, why can't we just say macros belong into res.handlers, and that's it. Punkt aus basta :-)

#5 by tobi at 2007/03/26 21:45

You mean in the future code like

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

plus a skin like

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

could result in

  "foo"
  "bar"

...?

#6 by hannes at 2007/03/26 23:02

I don't know. What do you think?

#7 by hannes at 2007/03/30 17:51

I updated the page above. I think I figures out a way that is both good to existing apps, and helps to make future apps cleaner and better structured.