Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-05-26:
[8:53] <hannesw> good morning[8:53] <hannesw> have been going through the wiki, filling some holes
[8:54] <hannesw> still so much missing
[8:54] <hannesw> problem is often documentation is there in the API docs, but not easy to find, and without context
[8:55] <hannesw> then, the demo app often has some context, but without links to the API docs
[8:56] <hannesw> and the wiki usually has nothing, or just a placeholder (e.g. http://ringojs.org/wiki/Skins/)
[8:57] <hannesw> so i think getting the wiki into shape is the next frontier
[8:59] <robi42> good morning
[8:59] <robi42> agreed
[9:00] <robi42> especially also explaining ringo's web framework more in detail would be good, imho
[9:06] <oberhamsi> yep. well i stopped with the webapp tutorial b/c skin rendering was about to change / get improved
[9:07] <hannesw> oberhamsi: what didn't work?
[9:08] <oberhamsi> <% foobar <% test %> %> .. resolving in custom macros
[9:08] <hannesw> i don't have any plans to add stuff to skins (more like removing stuff)
[9:08] <hannesw> what didn't work there?
[9:08] <robi42> nested macros?
[9:09] <oberhamsi> yes!
[9:09] <oberhamsi> earl had the smart words for whats going wrong :)
[9:09] <oberhamsi> if i have a custom macro and it's input is a custom macro, or an attribute i passed into skin, the latter doesn't get resolved
[9:09] <oberhamsi> that makes custom macros useless, b/c they only take hardcoded input
[9:11] <robi42> so the bottom-line is currently dynamic input to macros doesn't work as expected, right?
[9:11] <hannesw> oberhamsi: that's supposed to work that way
[9:11] <oberhamsi> yeps
[9:11] <hannesw> what you want is a filter
[9:12] <hannesw> nested macros are not supposed to be evaluated, the surrounding macor needs to do that
[9:12] <hannesw> that's how if/for etc macros work
[9:12] <hannesw> so in your example, you should define href as filter, not as macro
[9:12] * oberhamsi reads if/for macro
[9:13] <robi42> ah ok
[9:13] <oberhamsi> okay okay. i can deal with that :)
[9:13] <hannesw> just saying: that's the way it is. not saying it's the best solution
[9:14] <oberhamsi> so it's different to helma1. just asking
[9:14] <robi42> in any case, it should be documented, i guess :)
[9:14] <oberhamsi> i'll do smth with it and then i'll have an opinion
[9:15] <hannesw> it's probably different from helma
[9:16] <hannesw> well looking at it, it probably is a bug, and it probably can be fixed.
[9:18] <hannesw> ok, i'll fix it
[9:18] <hannesw> skin module needs some love anyway
[9:23] <oberhamsi> oh cool
[9:25] <ringostarr> 25b2f77 Simon Oberhammer: jsdoc: adds Object.defineProperties support
[9:25] <ringostarr> 4f15058 Simon Oberhammer: Merge branch 'master' of http://github.com/ringo/ringojs
[9:25] <ringostarr> c6dcc96 Simon Oberhammer: Merge branch 'master' of http://github.com/ringo/ringojs
[9:25] <ringostarr> c45047d Simon Oberhammer: Merge branch 'master' of http://github.com/ringo/ringojs
[9:25] <ringostarr> 4bca854 Simon Oberhammer: httpclient style: use defineProperties
[9:26] <oberhamsi> crap
[9:28] <oberhamsi> hannesw, didn't merge.. what just happend? should i undo
[9:28] <hannesw> oberhamsi: everything looks ok
[9:29] <hannesw> you might have done a "git rebase origin master" to avoid the merge commit
[9:29] <hannesw> but no problem i think
[9:29] <hannesw> or "git rebase origin/master" i think
[9:29] <oberhamsi> okay i hope so. i commited 3 merges
[9:30] <oberhamsi> i know about rebase, but wasn't aware my repo needed it :|
[9:30] <oberhamsi> is there something like `git outgoing` so i can see what would get pushed?
[9:30] <hannesw> not sure
[9:30] <hannesw> maybe earl knows :)
[9:32] <hannesw> wait a moment, i'm trying to get rid of the merge commits...
[9:35] <ringostarr> dd0ff61 Simon Oberhammer: httpclient style: use defineProperties
[9:36] <hannesw> oberhamsi i just force-pushed to ringo master to remove the merge commits
[9:36] <oberhamsi> hannesw, yeah! thanks
[9:36] <hannesw> can you make sure all your changes are there?
[9:36] <oberhamsi> i'll be more carefull
[9:36] <oberhamsi> i'll check
[9:36] <hannesw> you'll probably have to force-pull or whatever
[9:38] <oberhamsi> hannesw, worked. did normal pull and it said "forced update"
[9:38] <oberhamsi> unit tests pass and my changes are there too!
[9:38] <hannesw> ok. you see, git is very forgiving after all :)
[9:39] <oberhamsi> :)
[9:45] <robi42> btw, played a bit with html fragment caching via memcached (not sure if it would make sense to further wrap the java client api used into a package there): http://github.com/robi42/ringolog/commit/09bc861e9e14151174935a3e21a8d8f4ee24dc3f
[9:47] <oberhamsi> robi42, sure that's useful.
[9:47] <robi42> maybe we could add some kind of convenient cache macro or something
[9:48] <oberhamsi> why did you start with fragment caching? i guess you have a need? :)
[9:48] <oberhamsi> e.g. why not a middleware that caches all response
[9:48] <robi42> no, not really. was actually just curious to play a bit with it :)
[9:49] <robi42> yep, middleware would be a good anchor for conveniently caching whole responses
[9:50] <hannesw> robi42 nice
[9:51] <oberhamsi> robi42, well definitly nice demo
[9:51] <robi42> well, thanks :)
[9:57] <hannesw> btw, love that running rhino motive: http://log.robert42.com/17
[10:13] <robi42> maybe we should use it as ringo's "official" t-shirt :)
[10:15] <botic> jep! would be perfect ;)
[10:16] <botic> ohhh - xl/xxl sold out :( http://www.threadless.com/product/1000/Runnin_Rhino
[10:16] <hannesw> +1
[10:18] <hannesw> this one, too: http://www.threadless.com/product/2283/Overcompensating
[10:18] <hannesw> rhinos seem to be popular, which is good
[10:19] <robi42> :)
[10:26] <oberhamsi> lol running rhino. love it.
[11:05] <ringostarr> b54c047 Hannes Walln?fer: Evaluate nested macros in advance so they're always available.
[11:05] <hannesw> oberhamsi your skin example should now be working
[11:07] <oberhamsi> hannesw, nice, thanks. i'm so used to it working like that.
[11:07] <hannesw> well, the way we had it before was completely backwards
[11:08] <hannesw> built-in macro implementation is much simpler now that nested macros are simply there
[11:08] <hannesw> looking at template parser now for further simplification potential
[11:10] <oberhamsi> good to hear.
[13:18] <robi42> hannesw, not sure but possibly something got broken in if macro with last commit?
[13:18] <hannesw> what?
[13:18] <hannesw> did you run ant jar?
[13:18] <robi42> yep
[13:19] <robi42> looks like condition evaluates to true now when it actually shouldn't
[13:20] <hannesw> example?
[13:21] <robi42> http://github.com/robi42/ringolog/blob/hibernate/app/skins/index.html#L36
[13:22] <robi42> resp. http://github.com/robi42/ringolog/blob/hibernate/app/actions.js#L25
[13:22] <hannesw> what does <% authorized %> produce?
[13:23] <robi42> should be true|false|undefined
[13:23] <hannesw> no, i mean: what _does_ it produce
[13:24] <oravecz> can I make an XHR call from my ringo controller?
[13:24] <hannesw> oravecz we have a ringo/httpclient that has a similar API to the one in jquery, i think
[13:25] <oravecz> thanks, i'll check it out
[13:28] <robi42> hannesw: well, when passed from action to skin render it's actually null; how best to debug within skin?
[13:28] <hannesw> try this: <% echo <% authorized %> %>
[13:29] <robi42> undefined
[13:29] <robi42> so that should be fine
[13:30] <robi42> but it should evaluate to false in if macro then
[13:31] <hannesw> it might be "undefined" as string
[13:31] <robi42> right
[13:31] <robi42> http://github.com/ringo/ringojs/commit/b54c047361ae5bd015f64d7b6142edd776dda7ac#L0L303
[13:32] <robi42> and getEvaluatedParameter() calls evaluateExpression()
[13:33] <robi42> might be connected to that change somehow?
[13:34] <hannesw> obviously, since that's the commit that broke it
[13:34] <robi42> alright :)
[14:23] <hannesw> robi42 the problem is in ScriptableList, which converts undefined to "undefined"
[14:42] <ringostarr> 7f132d2 Hannes Walln?fer: Use less aggressive js-to-java conversion in ScriptableList and ScriptableMap
[14:43] <hannesw> robi42: if macro is working again
[14:43] <robi42> great, thanks
[15:02] <earl> not all is well in if_macro land
[15:07] * earl is debugging
[15:14] <earl> wah!
[15:15] <earl> it seems that somehow skin objects are now mutated while rendering
[15:16] <earl> and yes, that's indeed the case
[16:19] <earl> yay, found a simple fix
[16:46] <ringostarr> c2f82f4 Andreas Bolka: Fix nested macro expansion, add regression tests
[17:02] <earl> i consider this to be an evil hack, btw
[17:05] <hannesw_> earl thanks for that fix
[17:05] <hannesw_> i thought about this, but wasn't sure skins were supposed to be reusable
[17:06] <hannesw_> (i did some expermenting with skin caching, so that suggests the answer is yes)
[17:06] <hannesw_> anyway, i'll do some major refactoring in skins, so it's good to have the test case
[17:08] <earl> why did you expose the "namedParameters" map?
[17:08] <earl> it's not used anywhere at the moment, as far as i can tell
[17:10] <earl> someone writing a custom macro _could_ use it now, which is fine
[17:10] <earl> seems a bit unrelated to the original commit, though
[17:23] <hannesw_> to make named parameters writable
[17:23] <hannesw_> my plan is to transition fully to use plain js objects for macros
[17:24] <ringostarr> 6d24c15 Andreas Bolka: Typo
[17:24] <ringostarr> 18a5bed Andreas Bolka: Factor nested macro expansion into function
[17:24] <hannesw_> so it'll be just an array for anonymous parameters, and an object for named params
[17:24] <earl> mhm
[17:29] <earl> pure-js skins will be nice
[17:32] <earl> (and thanks for the explanation. i overlooked that named params were not writable before)
