Logs for the RingoJS IRC channel, as logged by ringostarr.

2010-06-18

[10:09] <hannesw> working on an a/b comparison between ringo skins and mustache...

[10:09] <hannesw> https://spreadsheets.google.com/ccc?key=0At-GsyW4f-HqdFFseEVjRlZONThZTzFSQ2hDbDhMS3c&hl=en

[10:25] <hannesw> so, pretty much done with the comparison

[10:25] <hannesw> would be nice to add other templating systems, such as gmosx's normal template

[10:25] <hannesw> btw, who's Anonymous user 1411? :)

[10:28] <oberhamsi> i guess that was me

[10:29] <hannesw> ah ok :) nice to know

[10:33] <hannesw> oberhamsi sent you an invitation to edit (if you want)

[10:33] <hannesw> also to gmosx in case he wants to add Normal Template

[10:33] <oberhamsi> hannesw, sure lets try that

[10:34] <hannesw> oberhamsi: sorry, try what?

[10:34] <oberhamsi> hannesw, invitation / colab

[10:34] <hannesw> should i make it world-editable?

[10:35] <oberhamsi> or can you invite ringojs google group?

[10:38] <hannesw> i don't think so

[10:38] <hannesw> at least i don't know how

[10:41] <hannesw> oberhamsi new ringodoc overview page is nice

[10:41] <oberhamsi> thx, and it encourages to write fileoverview docs :)

[10:42] <hannesw> yes

[10:42] <hannesw> maybe it should only display the first sentence or paragraph from fileoverview

[10:43] <hannesw> like javadoc does for class overview

[10:47] <oberhamsi> so far i think it works.. which class overview page in javadocs? like that? http://download.eclipse.org/jetty/stable-7/apidocs/index-all.html

[10:47] <hannesw> nope

[10:47] <oberhamsi> ah "class summary" here http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/continuation/package-summary.html

[10:47] <hannesw> nope again

[10:48] <oberhamsi> lol okay which one?

[10:48] <hannesw> i meant the method summary in any class view

[10:48] <oberhamsi> i like that i have all info on a page and can do ctrl-f search

[10:48] <hannesw> http://java.sun.com/javase/6/docs/api/java/lang/System.html

[10:49] <hannesw> the summaries only display the first sentence of the full description

[10:50] <oberhamsi> okay but that page is more like our http://nekapuzer.at/ringodocs/WebDev%20API%20(master)/ringo/encoding/

[10:50] <oberhamsi> module view

[10:50] <hannesw> yes, but the idea of only using the first sentence in an overview page still applies

[10:51] <oberhamsi> okay i will try, don't see the benefit yet

[10:52] <hannesw> shorter overview page, ability to write really long fileoverviews without clobbering overview page?

[10:55] <oberhamsi> well i like that there is so much info (clobber), it's not supposed to be read but searched. short overview = right side module list

[10:56] <oberhamsi> if it gets out of hand.. quick fix. also if you document a couple of modules, like most packages probably have, it makes even more sense

[10:56] <oberhamsi> *only a couple of modules

[10:59] <hannesw> ok

[12:05] <hannesw> pondering over the skins/mustache comparison...

[12:06] <hannesw> i think we do probably want something mustache-like

[12:06] <hannesw> either a hybrid, or and extende version of mustache

[12:06] <hannesw> i'll try to do a +/- list

[12:10] <hannesw> i think mustache wins bit with {{#xxx}} providing if/for/nested templates

[12:11] <hannesw> and ringo skins win with filters, mainly

[14:15] <oravecz> the subskin requirement for skins makes it a bit more verbose than mustache, but there is a lot to like about skins (filters and macros as you mentioned).

[14:15] <oravecz> that said, it would be great to be able to add mustache or ejs using the package concept

[14:16] <hannesw> oravecz you can mustache.js already as a package

[14:16] <hannesw> it's just not very commonjs-friendly

[14:16] <oravecz> ok

[14:16] <hannesw> http://github.com/janl/mustache.js

[14:17] <hannesw> ringo-admin install janl/mustache.js

[14:17] <oravecz> cool, thx

[14:18] <hannesw> well maybe something like mustache + filters + inline subtemplates could work

[14:18] <oravecz> would it make sense to process scripts in middleware?

[14:18] <hannesw> what do you mean by "process scripts"?

[14:19] <oravecz> sorry, skins is what i meant

[14:19] <hannesw> yes, why not

[14:19] <oravecz> I'm not using webapp.js in my portal code, so i have to rip out the skins processing from there

[14:20] <oravecz> I mean, does it make sense to move skins processing to middleware for ringo in general?

[14:21] <hannesw> gmosx does it that way

[14:21] <hannesw> depends on what it buys you, so to speak

[14:22] <oravecz> does gmosx refer to a project, or george?

[14:24] <hannesw> that's george, project is nitro

[14:24] <hannesw> http://github.com/gmosx/nitro

[14:33] <oravecz> should the set macro be modified so one can do <% set {param: value} %>, where 'param' gets added to the current context?

[14:34] <oravecz> might be a nice compromise to allow some support for variables without allowing embedded js

[14:39] <oravecz> or the macro could be called 'var' to avoid ambiguity

[14:39] <hannesw> yes, maybe

[14:39] <hannesw> not sure it's a good idea

[14:39] <hannesw> what would you need it for?

[14:44] <hannesw> robi42: any hints on how to quickly disable memcached in ringolog?

[14:44] <robi42> well, currently it's pretty much baked in, i guess :)

[14:48] <robi42> a possibility would be to simply comment out cache var assignment in model.js and archive widget macro call in base.html, i think

[14:48] <hannesw> wow, interface has made huge progress!

[14:48] <hannesw> very nice

[14:48] <robi42> thanks :)

[14:49] <robi42> tried to slicken it a bit

[14:49] <hannesw> i just set model.cache to this: {set: function() {}, get: function() {}}

[14:49] <robi42> ah right

[14:50] <hannesw> don't you think a personal weblog shouldn't need caching? :)

[14:51] <robi42> sure. was just driven by curiosity, actually. :)

[14:51] <hannesw> yeah, thought so ;)

[14:51] <robi42> it's more like a playground for me

[14:51] <hannesw> wow, hibernate logging is chatty, setting to WARN

[14:51] <robi42> it is

[14:56] <hannesw> robi42 url resolving doesn't work for story links for me

[14:57] <hannesw> getting 404

[14:57] <robi42> oh, that must be due to (relatively) recent changes in config.urls pattern handling, i think

[15:02] <hannesw> hm, it looks like the first pattern (which also matches) steals away the leading slash

[15:05] <robi42> hannesw, that should fix it: http://github.com/robi42/ringolog/commit/9fe40cd6cf3c588a963efa49a99103475be92a94

[15:07] <hannesw> you think so?

[15:08] <hannesw> i just reversed these rules that fixed it

[15:08] <hannesw> ok your changei might fix it, but the first rule still matches for /234, which is not quite what you want

[15:09] <robi42> true, reversing the rules better here.

[15:15] <hannesw> arghhh hating git

[15:15] <robi42> what happen? :)

[15:16] <hannesw> branch confusion

[15:16] <hannesw> i want to fork your ringolog/hibernate

[15:16] <hannesw> but i don't want to keep the other branch around

[15:16] <robi42> i see, sry for the branch mess in ringolog :)

[15:18] <robi42> probably should just merge its hibernate branch to master and delete

[15:18] <hannesw> yep

[15:18] <earl> `git push hns :master` and master shall be gone :)

[15:19] <hannesw> yea i thought i could map robi42/hibernate to hns/master, but that's not so easy i guess

[15:19] <hannesw> requires .git/config hacking

[15:19] <robi42> btw: at first, plan was to use berkeley, but then all my efforts moved towards hibernate branch :)

[15:21] <hannesw> can't delete hns/master:

[15:21] <hannesw> ! [remote rejected] master (deletion of the current branch prohibited)

[15:21] <hannesw> I'm on hibernate branch locally...

[15:21] <earl> sounds like github weirdness

[15:22] <hannesw> ok, not a big prob

[15:22] <earl> git clone http://github.com/robi42/ringolog.git ; cd ringolog ; git checkout -b tmp ; git branch -d master ; git checkout -b master origin/hibernate ; git branch -D tmp

[15:22] <earl> to have your local master track robi's hibernate

[15:22] <hannesw> k thx will try

[15:23] <earl> should work the same for your own hns/ringolog.git

[15:23] <earl> then force push master, and delete hibernate, and it should just work :)

[15:24] <hannesw> woohoo, worked!

[15:24] <hannesw> thanks earl

[15:25] <earl> you're welcome

[15:25] <hannesw> robi42 my plan is to simplify ringolog a bit for my own use

[15:25] <robi42> oh wow. cool

[15:25] <robi42> _even_ simpler? ;)

[15:25] <hannesw> make things optional, such as memcached or disqus

[15:25] <robi42> i see

[15:26] <hannesw> i don't like disqus

[15:26] <robi42> i do

[15:26] <robi42> are you going to impl. comments support on your own?

[15:26] <hannesw> no plan

[15:27] <robi42> ok

[17:13] <oberhamsi> i think i put too much crap/options in statifier

[17:14] <oberhamsi> currently you can render multiple repos (what we have on ringojs.org), a single repo (no repo switching, no repo overview), or a single module (single html page)

[17:14] <oberhamsi> i would ditch single module view.. not sure

[20:08] <oravecz> is there a way to pass an object literal as a param to a macro? Tried <% mymacro {key: 'value' } %>, but that doesn't work...

[20:18] <oberhamsi> oravecz, i don't think so but you can do named parameters <% mymacro key='value' %>

[20:18] <oberhamsi> ...and then tag.getParameter('key') if that helps

[20:19] <oravecz> thx oberhamsi, i'm using that in some places. I guess the macros are just written to work with string parameters and object literals don't work...

[20:23] <oberhamsi> oravecz, something like this works http://ringojs.pastebin.com/kfJeuF1Q

[20:24] <oravecz> that's interesting...

[20:25] <oravecz> I suppose I could also use <% set {...} mymacro %> as an ugly workaround :)

[20:28] <oberhamsi> haven't needed `set` yet :)