Hopbot log for 2008-01-10 - Helma IRC channel: #helma on irc.freenode.net

2008-01-10:

[6:07] <bard> knock knock
[8:07] <zumbrunn> bard: who's there?
[8:08] <bard> hi zumbrunn :-)
[8:08] <bard> congratulations on the 1.6.1 release
[8:08] <zumbrunn> ah... it's *you* ;-)
[8:08] <zumbrunn> thanks!
[8:09] <bard> I have a small report which is probably Rhino-related, but affects the e4x skins example on your blog
[8:10] <bard> http://pastebin.ca/849165
[8:11] <bard> replacing "new XML(...)" with "eval(...)" works.
[8:15] <zumbrunn> hmm, just checked whether I get that with a current rhino 1.7 build as well
[8:15] <zumbrunn> and I do, unfortunately
[8:16] <bard> I'm stress-testing e4x and things don't look very good overall (at least compared with spidermonkey)
[9:05] <bard> zumbrunn: code at http://dev.helma.org/Wiki/Helma+2+Templates+-+czv/ does not handle nested loops, correct?
[9:08] <zumbrunn> that's very possible
[9:08] <zumbrunn> does it even work at all still?
[9:10] <zumbrunn> I have finally just started to redo openmocha from scratch, using e4x for its "skins"
[9:11] <zumbrunn> but I'm not using the approach I mentioned there so far because I'm combining it with the built-in skins
[9:11] <zumbrunn> so that the macro features in skins can be used, before the object is converted into e4x
[9:18] <bard> zumbrunn: does it even work at all still? -> haven't tried, just asking, but I see you iterate over view..*.(@loop...), so that will catch inner loops as well
[9:18] <bard> I was trying to come up with an e4x-based templating system too but so far looks like the only sane way would be to visit the whole tree element-by-element, and I'm not sure how expensive that would be in pure js
[9:29] <zumbrunn> heh... it's been a long time since I looked at that Helma 2 template proposal
[9:29] <zumbrunn> what I'm doing now is actually similar in some regards
[9:30] <zumbrunn> the e4x "skins" are made available as properties of this.views
[9:30] <zumbrunn> and the views can have controls
[9:31] <zumbrunn> but instead of the control being a direct property of the view, the controls are now separate from the views in this.controls
[9:32] <zumbrunn> that way controls can be set independently of views
[9:32] <zumbrunn> anywhere in the prototype chain
[9:32] <zumbrunn> or anywhere in the path hierarchy
[9:32] <bard> very interesting, but what exactly are controls? :-)
[9:33] <zumbrunn> for example, a file called foo.skin in a helma apps prototype's dir becomes available as this.views.foo
[9:34] <zumbrunn> this.views.foo returns an e4x object
[9:34] <bard> that was the example from your blog I was referring at the beginning (the one Rhino broke)
[9:35] <zumbrunn> if there is a this.controls.foo (a function), then this.views.foo returns the result of that function
[9:35] <bard> hmm, yes. so this.controls.foo produces xml too, right?
[9:36] <zumbrunn> well, in other words, before this.views.foo returns the e4x converted skin, it checks whether there is a this.controls.foo...
[9:37] <zumbrunn> if this.controls.foo exists, it is called and foo.skin is pathed into the function a parameter...
[9:37] <bard> ah
[9:38] <zumbrunn> the this.controls.foo function can then use view.render() to convert it to e4x...
[9:38] <zumbrunn> and return that, or do whatever else and return something else
[9:38] <bard> I see
[9:39] <zumbrunn> this way, the control can still massage data before rendering the skin
[9:40] <zumbrunn> and when view.render() is used to do the conversion to e4x, you get to leverage all the built-in macro features of helma
[9:40] <bard> there's a risk to be generating significant chunks of view in the control, I guess
[9:41] <zumbrunn> could be, we'll see
[9:41] <zumbrunn> one just needs the right set of conventions to follow :-)
[9:42] <bard> yeah :-)
[9:43] <bard> I'm somewhat fond of pure-xhtml templates, like ZPT (although I've never used that one), are you familiar with them?
[9:43] <zumbrunn> nope
[9:43] <zumbrunn> I don't think I've come across that before
[9:44] <zumbrunn> I guess using e4x is a good step in that direction
[9:44] <zumbrunn> since it will throw errors on any malformed markup
[9:45] <bard> check out the example here: http://hyperstruct.net/projects/seethrough (it's a mini-clone I wrote in erlang)
[9:45] <zumbrunn> oh, yes... btw... if the control function returns something that isn't an e4x object, it's converted to e4x
[9:46] <zumbrunn> so, what you get from this.views.foo should always be an e4x object
[9:46] <bard> ok
[9:49] * bard is very tempted to compile the xml tree down to closures and cache it...
[11:09] <bard> seems to work, http://pastebin.ca/849321
[11:15] <zumbrunn> what's your intention? that helma would do this automatically with files that have a certain filename extension, for example?
[11:19] <bard> you're thinking farther than me :-) but yeah, could be an idea
[11:19] <zumbrunn> anyway, leveraging file suffix conventions more in helma would be a good idea, I think
[11:20] * zumbrunn for example still thinks foo.macro should map to foo_macro
[11:20] <zumbrunn> like foo.hac does for foo_action
[11:21] * bard notices he got an undefined in the output on pastebin (argh)
[11:26] <bard> is the routine that resolves a skin name to a skin file exposed to javascript?
[11:39] <zumbrunn> bard, not currently
[11:39] <bard> ok
[11:39] <zumbrunn> making all this configurable through js would be nice, though, I think
[16:17] <bard> did another bit of hacking: http://pastebin.ca/849533 - now it's reeeally time to get some sleep :-) g'night

 

 

In the channel now:

Logs by date: