Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-06-07:
[0:50] <oravecz> i just found this xhr-like gist: http://gist.github.com/357388[0:50] <oravecz> trying it now
[8:42] <gmosx> hello
[8:43] <hannesw> good morning
[8:43] <hannesw> robi42 your url dispatching proposal is interesting
[8:44] <robi42> good morning
[8:44] <robi42> glad to hear
[8:44] <hannesw> i already said i don't like the exports.METHOD.pattern order - i think that's the wrong way round
[8:44] <hannesw> but moving patterns into action is an idea i find interesting
[8:45] <hannesw> i'm thinking maybe all this should be attributes/properties on the action functions
[8:45] <gmosx> hannesw: where is getResource() defined?
[8:45] <hannesw> gmosx it's a native global function
[8:46] <hannesw> like require()
[8:46] <gmosx> can I get an absolute path from getResource()?
[8:46] <robi42> what i was mainly concerned about while thinking about later on then was what to do if one got more than one GET method to the same resource function name
[8:46] <gmosx> ie,
[8:46] <gmosx> getResource("../path/to/file").toAbsolutePath()
[8:46] <hannesw> getPath() - but it's not the absolute path for webapp resources
[8:47] <hannesw> you can't get the absolute path from web app resources, and that's semi-intentional
[8:47] <hannesw> robi42: I don't think we should support that
[8:47] <gmosx> I would like to load a text file relative to the current module, is this possible?
[8:47] <robi42> like `GET /documents` and `GET /documents/{id}` both routing to module-name.documents
[8:47] <hannesw> js just doesn't support overloading, and it's easy to work around with a simple if statement
[8:47] <robi42> true
[8:47] <gmosx> i thought getResources() could help
[8:48] <robi42> or defining function dispatch in config.urls accordingly
[8:48] <hannesw> gmosx yes... getResource(...).getContent()
[8:49] <robi42> having an additional `documentsMain` or something like that then
[8:49] <hannesw> robi42, can you explain that some more?
[8:49] <robi42> ok, example from above
[8:49] <robi42> the two GETs
[8:50] <hannesw> gmosx, for relative paths just use something starting with "./xxx" or "../yyy"
[8:50] <gmosx> ah
[8:50] <gmosx> .getContent() can I pass the encoding too?
[8:51] <gmosx> I would like to get a path that I could use with fs.read()
[8:51] <robi42> then one could have `exports.urls = [["^/", "./actions"], ["^/documents/([1-9]\\d*)", "./actions", "documentsMain"]]`
[8:51] <robi42> (as an example)
[8:51] <hannesw> gmosx yes (encoding)
[8:52] <hannesw> robi42, well you can do that already, right?
[8:52] <robi42> and in actions.js: `exports.documents` and `exports documentsMain`
[8:52] <robi42> right
[8:53] <robi42> difference would be having the http methods as properties of the actions.js exports then
[8:53] <hannesw> gmosx you can't get a fs path for a webapp resource, it might not be a file, better use resource api
[8:53] <robi42> as you proposed on ml reply
[8:54] <hannesw> well I'm pretty sure i want the methods as properties of the individual actions, not as top level exports
[8:54] <hannesw> what we could do is add the pattern as properties to the actions as well
[8:54] <robi42> a more radical approach (change-wise) would be: http://gist.github.com/427546
[8:55] <hannesw> i would then prefer this:
[8:55] <hannesw> exports.documents = function|object literal
[8:55] <hannesw> exports.documents.pattern = "^/documents";
[8:56] <hannesw> not sure about "pattern", but the idea is to add this info _into_ the action namespace
[8:57] <robi42> well, actually i would prefer having the url pattern closer to the actual action :)
[8:57] <hannesw> isn't that close?
[8:58] <oberhamsi> i like the method dispatch in actions, but wouldn't attach url pattern to actions.
[8:58] <hannesw> why not?
[8:58] <robi42> i meant to say i like to go into that direction
[8:58] <oberhamsi> if i have several modules.. like we have on ringojs
[8:59] <oberhamsi> i'd rather have seperation between the actions and what they map to
[8:59] <oberhamsi> if i grab the "ringo-blog' module i don't want to be forced to have it under "/blog"
[8:59] <oberhamsi> i'd have to chnage it's sources instead of just my config to attach it to another url
[8:59] <hannesw> oberhamsi you have that already, and that would stay that way
[9:00] <oberhamsi> oh okay exports.documents.pattern = "^/documents" seems to hardcode url in actions.js
[9:00] <hannesw> if you add an app into a sub-url-space, the paths it matches against are already trimmed
[9:00] <oberhamsi> yes but it must be "^/documents".... hm..
[9:01] <oberhamsi> seems strange to force urls in actions. i grab an app and the app has hardcoded urls and i can't change that.
[9:02] <oberhamsi> but i think that's the general direction you want to take... lots of relative urls in skins & actions having fixed urls.
[9:02] <hannesw> oberhamsi I'm not sure you're aware of how ringo/webapp dispatching works - this would change exactly nothing
[9:02] <hannesw> it just moves from config.js to actions.js
[9:03] <oberhamsi> ^^ yes. but i grab an app i usually define my own config.js and don't touch actions.js
[9:03] <hannesw> ah ok, i see your point
[9:03] <hannesw> well you can't usually just change url mappings in an app's config.js
[9:03] <hannesw> that will usually break the app, wouldn't it?
[9:04] <oberhamsi> yes, that's what i meant with relative urls in skins
[9:04] <hannesw> what about them?
[9:04] <oberhamsi> maybe it's a good thing. forcing relative urls. just very different from how others do it - reverse url looup, etc
[9:04] <oberhamsi> lookup
[9:05] <hannesw> if you want an app to be "pluggable", you have to use <% href %> macro or something equivalent
[9:05] <hannesw> relative urls will work for very simple apps
[9:05] <oberhamsi> okay i see what you mean
[9:06] <hannesw> when I built ringojs.org, i fixed/rewrote some of the embedded apps (ringowiki, jsdoc) to use <%href%> for url generation
[9:06] <hannesw> you can use absolute urls if you don't care about embeddability
[9:06] <oberhamsi> i'm probably just too used to href() or any reverse url lookup
[9:07] <oberhamsi> others argue against what we do. they say it's not DRY b/c you define urls in skins & in config (or actions)
[9:07] <hannesw> well <% href %> in ringo works pretty much like in helma, except only per-application. it doesn't generate intra-app uri paths
[9:08] <hannesw> well i think helma was unique in that regard in that each object/piece of code knew exactly where it was in the global URL space
[9:09] <oberhamsi> that's what django, rails and others do with reverse lookup.
[9:09] <hannesw> but that was a very costly abstraction that sometimes broke, as you know
[9:09] <hannesw> how do they implement it?
[9:09] <robi42> personally, i'd prefer less url routing magic than the opposite
[9:09] <oberhamsi> i think very hard to implement, took long time
[9:10] <oberhamsi> but i can see, how what hannesw robi42 propose would remove that problem mostly.
[9:10] <oberhamsi> <% href %> and urls pattern in config.js probably good enough
[9:11] <hannesw> for now, yes. looking at reverse lookup in django and rails
[9:11] <oberhamsi> DRY people hammered into me that defining your urls once in url patterns & then again in skins is terribad.
[9:13] <robi42> btw, also inside rails community there's some tending towards getting rid of the automagic url routing mechanisms now
[9:13] <robi42> see, e.g.: http://blog.peepcode.com/tutorials/2010/rethinking-rails-3-routes :)
[9:15] <hannesw> yes, saw that on ringolog :)
[9:16] <hannesw> these are interesting also :
[9:16] <hannesw> http://blog.jeffhui.net/2010/02/djangos-flaws/
[9:16] <hannesw> http://blog.jeffhui.net/2009/03/rails-and-django/
[9:16] <hannesw> although very high-level
[9:17] <oberhamsi> but rails doesn't want to get rid off url reference by model instance?
[9:19] <oberhamsi> okay, just wanted to trigger that train of thought.. i'm sure others, indoctrinated like me, will show up :)
[9:20] <oberhamsi> those links talk about removing more duplication .. i don't understand rails enough to see what they mean, but they're not unhappy with reverse looup afaict
[9:21] <robi42> yes, they would merely keep the model/controller-plugged url path generation part
[9:22] <robi42> and improve the actual action url routing
[9:22] <oberhamsi> so you can still get an url per model, right?
[9:22] <robi42> yep
[9:22] <robi42> per controller rather
[9:22] <oberhamsi> okay
[9:23] <robi42> you'd still be able to say something like `<% documents_path %>` inside a view
[9:23] <oberhamsi> so django's & rails' implementations are terrible from what i gather. maybe that's a sign not to try it that way
[9:23] <robi42> given you've got a related documents controller
[9:24] <robi42> well, as i said, i'm happy with less url routing magic :)
[9:26] <oberhamsi> :) yes that's whay i like about what i see in gist / on ML ... it's comprehensible, and so is probably the implementation
[9:52] <hannesw> should we rename <% href %> to <% url %>, and maybe introduce more of the high level helpers rails has?
[9:53] <hannesw> http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html
[9:53] <hannesw> (albeit with manual routing :)
[10:03] <robi42> +1 for that (tho, i actually like the `href` naming; probably helma-nostalgia-related) :)
[10:11] <oberhamsi> helpers +1
[11:07] <rist> hi - I'd need again some guidance how to do something in ringojs - this time I'd like to set up a regular task which writes a message to all clients which are connected to a websocket of the app
[11:07] <rist> I set up a setInterval() in main.js and included the websocket.js - but I'm not sure how to access the "members" of the websocket
[11:09] <robi42> hi rist, what's websocket.js exporting?
[11:11] <hannesw> rist websockets is a moving target, i wouldn't use it for real apps currently
[11:12] <robi42> let's say it exports `foo` and you `include('websocket')` in another module: you can simply call `foo` inside the latter module then. or am i misunderstanding something?
[11:12] <rist> currently it exports only serverStarted/serverStopped - so only stuff needed for registering as extension
[11:13] <rist> ok - so I could just export a function in websocket.js for sending a message to all subscribers
[11:13] <robi42> right
[11:15] <robi42> btw, another (actually preferred way) of importing things from another module is to use so-called destructuring assignment with `require`
[11:16] <robi42> like: `var {foo} = require('bar');`
[11:16] <robi42> (sry for typos)
[11:21] <rist> that way only foo of {foo:bar, whatever:x} is imported, right?
[11:22] <robi42> exactly
[11:23] <robi42> if you'd want both "members" you could, e.g.: `var {foo, whatever} = require('bar');`
[11:24] <hannesw> rist what are you using for websocket? the package listed on the wiki page?
[11:24] <rist> yes
[11:24] <rist> but saw that you updated your gist code fragment
[11:25] <rist> and updated it in the package manually as well
[11:25] <hannesw> well the problem i have with that is it isn't really a generic package, it's more like a demo hello world app
[11:25] <hannesw> but it's in the ringo namespace, and i don't think that's a good idea
[11:25] <rist> yes definitely - without even an exposed send() method it's not much of a generic thing
[11:25] <rist> ah ok
[11:26] <hannesw> i just wrote that as a proof-of-concept thing, and robi42 packed it up, but i think much more thought is needed
[11:26] <rist> yes - for sure
[11:26] <robi42> or, of course, put them all in a namespace inside the importing module, like: `var bar = require('bar');`
[11:26] <hannesw> if you want something working on all browsers, you should use ringo-cometd imo
[11:27] <rist> I'm not really sure how to generalize some websocket api have to talk to mgroh - he researched that a bit more and started using the concept of websocket "protocols"
[11:28] <rist> for backwardscompability you should look at http://www.kaazing.com/
[11:29] <rist> they fallback on flash or activex stuff
[11:29] <hannesw> yes, right. that's exactly how cometd works
[11:29] <hannesw> it can work on top of websocket, but also ordinary http
[11:31] <rist> no - they fall back on flash sockets
[11:31] <hannesw> well i'm talking about cometd.org and jetty (what ringo uses)
[11:31] <rist> ok
[11:32] <rist> was not aware that comet is moving to websockets - thought that they still do http long poll
[11:32] <rist> another thing - i didn't find anything about how to host static files
[11:32] <hannesw> they usually do that. but they implemented cometd on top of websocket - i think it's in jetty 8 and cometd 2
[11:34] <hannesw> static files in ringo webapps?
[11:34] <hannesw> have a look at the bundled apps
[11:34] <hannesw> any special needs - security?
[11:34] <rist> no
[11:35] <rist> ah - basically setting exports.httpConfig = { staticDir: './static'}; and that
[11:35] <rist> 's it
[11:36] <rist> what about adding a searchbox to the ringojs.org sidebar (just plain powered by google)
[11:37] <robi42> +1
[11:40] <hannesw> rist, a more flexible way to define static resources is this:
[11:40] <hannesw> http://github.com/ringo/ringojs.org/blob/master/config.js#L19-24
[11:41] <rist> thanks
[11:54] <hannesw> google site search isn't free??? http://www.google.com/sitesearch/
[11:56] <robi42> what about http://www.google.com/cse/ ?
[12:07] <rist> what just about a form which posts the query and adds "site:ringojs.org"
[12:11] <oberhamsi> this is what cse does: /search&q=FOOBAR&sitesearch=*ringojs.org&domains=*ringojs.org
[12:56] <hannesw> so any consensus on the http method dispatching issue?
[12:56] <hannesw> robi42, oberhamsi?
[12:57] <robi42> what do you think about the somewhat more "radical" proposal in http://gist.github.com/427546 ?
[12:58] <oberhamsi> exports.documents = function|object literal // looks good. obj literal being {GET: func, POST: func}
[12:59] <hannesw> robi42, i don't like it, sorry
[12:59] <hannesw> you could try it out and see if it works for you
[12:59] <robi42> ok, i'm fine with the other one as outlined by oberhamsi
[13:00] <hannesw> ok, guess I'll give that a try then
[13:00] <robi42> +1 :)
[13:00] <oberhamsi> cool
[13:01] <robi42> and what about url patterns?
[13:01] <oberhamsi> ... also i'm already semi-convinced our manual routing leads to something good
[13:01] <robi42> `exports.documents.pattern = '^/documents'` ?
[13:02] <oberhamsi> how ever it may look :)
[13:02] <hannesw> robi42 I'd leave url patterns as they are, i.e. in config.urls
[13:02] <oberhamsi> i think it's not really up for debate
[13:03] <robi42> alright, fine with me as well :)
[13:55] <ringostarr> 689a624 Hannes Walln?fer: Support for HTTP-method specific actions: { GET: function()..., POST: function()... }
[13:55] <hannesw> well that seems to have been easy...
[13:55] <hannesw> still not 100% convinced
[13:55] <hannesw> especially since this should be the _standard_ way to declare an action
[13:56] <hannesw> i.e. in most cases, you should only declare a GET action
[13:56] <hannesw> but the implicit behaviour of the current scheme is still to make the action handle every HTTP method...
[13:57] <hannesw> maybe we should support the simple function mapping only for GET requests?
[13:58] <hannesw> and require an explicit action for every other HTTP method?
[14:03] <oberhamsi> hm, but then we'd have no way to define an action handling more then 1 method
[14:04] <hannesw> true
[14:06] <hannesw> well i think this is a good step towards providing method aware dispatching
[14:07] <hannesw> question is should we convert our own apps to it?
[14:07] <hannesw> we probably should
[14:07] <hannesw> it's not so bad actually
[14:07] <hannesw> for example, demo index action looks like this:
[14:07] <hannesw> http://ringojs.pastebin.com/pJfQt0XE
[14:08] <hannesw> oops, doesn't work. first bug :)
[14:17] <ringostarr> f88e725 Hannes Walln?fer: Make method-specific actions work in more places.
[14:26] <hannesw> hm, i must say i actually like this a lot: http://ringojs.pastebin.com/DwufPBRM
[14:45] <hannesw> (reposting because it seems i lost connection before...)
[14:45] <hannesw> this is what the demo app's actions.js looks when converted to
[14:45] <hannesw> new method-specific actions: http://gist.github.com/428748
[14:45] <hannesw> what do you think?
[15:03] <oberhamsi> yes looks nice, self explanatory
[15:03] <b41l3y> Hi All- We've been using the narwhal-mongodb package to handle our ringo/mongo connectivity. We just noticed that a mongodbstore was released last week and would love to have it take the place of the narwhal-mongodb package. My question is, how stable is this initial release of mongodbstore? Any known issues to be aware of?
[15:08] <daian> hello
[15:09] <daian> i'm having trouble running the ringo demo file
[15:11] <oberhamsi> daian, what error do you get or what's not working?
[15:12] <daian> i'm getting a syntax error, but i think it might be cause i'm trying to run the demo through the ringo shell
[15:13] <oberhamsi> what's the error? or can you paste somewhere what you're trying to do?
[15:15] <daian> hmm, ok, my first problem was trying to run the demo viathe ringo shell
[15:15] <daian> now the onlyproblem running the demo is a java.lang.NullPointerException
[15:16] <oberhamsi> how do you run the demo?
[15:17] <oberhamsi> ringo apps/demo/main.js ?
[15:17] <daian> ringo ../apps/demo/main.js yeah
[15:18] <oberhamsi> daian, can you pls post the whole output here http://ringojs.pastebin.com/
[15:19] <oberhamsi> brb
[15:21] <daian> there's no other besidesa null pointer exception
[15:21] <daian> java is up to date, and i'm running win xp
[15:21] <hannesw> daian can you try running ringo with -V switch?
[15:21] <hannesw> that should give you a java stack trace
[15:22] <daian> ok, i'll post that
[15:23] <daian> ok, this is what i get:
[15:23] <daian> http://ringojs.pastebin.com/qNZz3XQn
[15:24] <hannesw> thanks. can you tell me the steps you do to get this?
[15:25] <daian> i just type ring ../apps/demo/main.js into a command window
[15:25] <daian> *ringo
[15:27] <hannesw> that's weird
[15:28] <daian> i can create a new app using the ringo admin and it works, but the test app doesnt
[15:28] <hannesw> are you sure your jar files are up to date (you ran "ant jar" after updating)
[15:29] <daian> possibly not, i downloaded the .zip of ringo 0.5, didn't do anything with ant
[15:29] <hannesw> oh ok
[15:29] <hannesw> ah... i also get a nullpointerexception if the file doesn't exist
[15:30] <hannesw> which is a bug of course
[15:30] <hannesw> are you shure ../apps/demo/main.js is the correct path?
[15:33] <hannesw> ok, it's a combination of things: running a file starting with ".." that doesn't exist
[15:33] <daian> i believe it is,since i get a FileNotFoundexception otherwise
[15:34] <daian> ahh
[15:34] <hannesw> what directory are you in?
[15:34] <hannesw> if you're in ringojs install dir, it's just apps/demo/main.js
[15:35] <daian> ahhhh, that's the problem
[15:35] <daian> i was just in a random cmd starting directory
[15:38] <daian> thanks!
[16:08] <earl> b41l3y: i think mongodbstore is very much a work in progress. but i guess rist_ can tell your more details :)
[16:11] <rist_> yes I can (but I'm currently cooking in the kitchen) - is it ok to answer questions in an hour?
[16:29] <b41l3y> Thanks earl!
[16:30] <b41l3y> We're going to stick with the narwhal-mongodb package for now but I'm interested in the mongodbstore so I'll keep an eye out for sure.
[16:34] <rist_> so - back from the kitchen
[16:35] <rist_> what the ringo-mongostore does is to implement the ringo storage layer
[16:36] <rist_> so you can do something like this:
[16:36] <rist_> include('ringo/storage/mongodbstore');
[16:36] <rist_> store = new Store('server', 27017, 'dbName');
[16:36] <rist_> Book = store.defineEntity('book');
[16:36] <rist_> var b = new Book({title: "DBs for dummies"});
[16:36] <rist_> b.save();
[16:36] <rist_> and it takes care of (hopefully) everything
[20:39] <hannesw> interesting: http://ozmm.org/posts/higher_order_mustache.html
[20:39] <hannesw> have to take another look at mustache.js
[20:44] <hannesw> http://mustache.github.com/mustache.5.html
[20:56] <hannesw> normal template also looks cool
[20:56] <hannesw> http://github.com/gmosx/normal-template
[21:02] <oberhamsi> higher order is sweet
[21:03] <oberhamsi> would that open similar possibilities: being able to pass a subskin to a macro / filter
[21:04] <hannesw> yes
[21:04] <hannesw> we talked about that a long time ago for helma
[21:04] <oberhamsi> ah :)
[21:05] <hannesw> I'm thinking maybe we should just drop our own skinning implementation, and go with something that's out there
[21:06] <hannesw> how's the tutorial going, oberhamsi?
[21:07] <oberhamsi> needs a lot more work :) but i'm picking it up
[21:07] <hannesw> just saw, the fixme list is getting long... :)
[21:07] <oberhamsi> i have my todos on gist. i want to plow through mentioning everything in there & then make it more concise / readable
[21:07] <oberhamsi> lol yes
[22:27] <earl> the new http-method handling stuff does not look too bad
[22:27] <earl> but i think it's too verbose for the common case
[22:28] <earl> which is: having an action that just want's to handle GET
[22:30] <earl> so maybe we should switch defaults
[22:31] <earl> make `exports.foo = function (req) {}` a shorthand for `exports.foo = {GET: function (req) {}`
[22:32] <earl> and add a special key for "catch all" methods, for those cases this is still needed
[22:33] <earl> could be _ANY, for example: `exports.foo = {_ANY: function (req) {}}` or even just `_`
[22:51] <earl> hannesw: you might wanna have a quick look at the logs :)
[22:53] <hannesw> ok, read it. not sure
[22:54] <hannesw> that's a consistency vs. economy thing
[22:55] <hannesw> what you propose is econimic, but very inconsistent
[22:55] <hannesw> i'm not even sure we need the ANY case
[22:56] <hannesw> it's probabyl nice to have
[22:57] <hannesw> ANY is convenient to share code between methods, e.g. POST with incomplete input -> render form again -> same code as GET
[23:01] <earl> well, leaving the ANY aside, my proposal is actually just as consistent as the current behaviour
[23:02] <earl> there's the method-based dispatching when the action is an object ({}), and there's a special-case dispatching when the action is a function
[23:02] <earl> currently, the special case is "don't do method-based dispatching at all, but route all http methods to this action"
[23:03] <earl> w/my suggestion, the special case is "only dispatch GET"
[23:04] <earl> and as that's a very prominent user-facing API, i think it should really be optimised for the common case
[23:04] <earl> i don't worry too much, as the current implementation can just be ignored at not loss
[23:05] <earl> it's just that http://gist.github.com/428748 adds a lot of noise for almost no gain
[23:06] <earl> the only gain i see is a somewhat improved self-documentation that all actions (except upload) really only want to handle GETs
[23:08] <earl> at the cost of 2 extra lines and one extra level of indentation per action
[23:08] <earl> with 6/7 functions actually being pure-GET, i think that's a sensible thing to make the default behaviour
[23:11] <earl> 4/6 for ringowiki, 3/3 for jsdoc, 2/2 for ringobot, 2/3 for ringolog, 0/3 for storage
