Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-06-17:
[8:19] <oberhamsi> hm, skinning: this should work, right? http://ringojs.pastebin.com/BHgZSavV[8:20] <oberhamsi> <% for item in <% items | fooFilter %> render itemView %> filer doesn't get called fooFilter
[8:52] <hannesw> oberhamsi yes i think it should work
[8:52] <oberhamsi> okay it does not :) i pasted simple example in pastebin
[8:55] <oberhamsi> now trying to write my own render_filter ... does a filter have access to the whole context? via `tag` parameter maybe?
[9:02] <ringostarr> 10b1f79 Robert Gaggl: * implemented commonjs unit testing 1.0 spec, moved assertion methods into own assert.js module
[9:02] <ringostarr> fb963ba Robert Gaggl: removed leftovers
[9:02] <ringostarr> 2f6dbf2 Robert Gaggl: prefixed subobjects with "test", the runner is now commonjs conformant too
[9:02] <ringostarr> 7315fa1 Robert Gaggl: moved assert and unittest into top module directory, renamed the latter to "test.js" to follow commonjs spec
[9:02] <ringostarr> 1c4e2dd Robert Gaggl: added inline docs
[9:02] <ringostarr> 3342840 Robert Gaggl: comparators (currently unused) is now a const
[9:23] <oberhamsi> re ^^ this is what i came up with, not perfect b/c 'item' name is hardcoded but works for now http://helma.pastebin.com/ckVfVHZ6
[9:54] <robertg> hi everybody
[9:58] <hannesw> hi robertg!
[9:59] <hannesw> thanks for the unit testing work!
[9:59] <hannesw> thought you were gone, so i merged it already :)
[9:59] <robertg> no, i'm still not on vacation :)
[10:00] <hannesw> sorry about that, but good for us ;)
[10:00] <hannesw> well it's great to have commonjs unit testing!
[10:00] <robertg> there are two tests failing, and a third one disabled
[10:00] <hannesw> yes, i saw that
[10:01] <hannesw> i looked at them but didn't understand what's going on
[10:01] <robertg> one big difference is the prototype checking
[10:01] <robertg> the spec says to compare the prototype property of actual and expected values
[10:01] <robertg> which doesn't make much sense imho
[10:01] <robertg> as .prototype is undefined for instances
[10:02] <hannesw> for what method?
[10:02] <robertg> 7.4
[10:02] <robertg> deepEqual
[10:03] <robertg> also 7.3 is problematic, i'd say, as it uses == for comparison
[10:04] <hannesw> so if "prototype" property is undefined for both objects, that's ok, isn't it?
[10:04] <robertg> yes, but comparing .prototype makes this pass:
[10:04] <robertg> assert.deepEqual(["a"], {0: "a"})
[10:05] <hannesw> hm, ok
[10:05] <robertg> which i don't think is right
[10:05] <robertg> that's why i switched to Object.getPrototypeOf() for comparison
[10:06] <robertg> but with this we're not strictly commonjs compliant
[10:06] <hannesw> hm, i think it's better to stick to the spec
[10:09] <robertg> i'm not sure, i tend to interpret this as wrong wording in the spec
[10:10] <robertg> see http://groups.google.com/group/commonjs/msg/501a7e3cd9a920e5
[10:11] <hannesw> ok
[10:12] <robertg> at least this is part of the "known spec bugs"
[10:12] <hannesw> so the two failing tests are related to this or something else?
[10:13] <robertg> the one failing because of 7.4 is currently commented out
[10:13] <robertg> the first failing test is because i didn't implement a narwhal speciality that is not part of the spec
[10:14] <robertg> due to 7.3 assert.deepEqual("", [""]) passes
[10:14] <robertg> but in the narwhal implementation they took care of this special case and made it fail
[10:15] <robertg> the second test fails because it's not part of the spec
[10:15] <hannesw> ok, cool. i feel pretty good about this.
[10:15] <hannesw> it's ok to have a few tests fail, will remind us to resolve these issues in time
[10:15] <robertg> thought so too
[10:16] <robertg> in general i believe that the spec should be more strict, eg. no comparison using ==
[10:17] <robertg> but that's subject to discuss on the commonjs mailing list
[10:17] <hannesw> right
[10:17] <hannesw> closing http://github.com/ringo/ringojs/issues#issue/24
[11:05] <hannesw> what do you think about that running rhino on our front page?
[11:05] <hannesw> http://ringojs.org/wiki/
[11:05] <hannesw> it's just a try, i can remove it if it's a stupid idea
[11:15] <robi42> i, for one, like it (concerning the running rhino, that is)
[11:34] <oberhamsi> i was never sure if that is related to djangopony.com (okay pony not unicorn)
[13:12] <oberhamsi> again statified, no more sexy ajax stuff *phew* http://nekapuzer.at/ringodocs/
[14:40] <hannesw> oberhamsi that documentation is rendered to html files, right?
[14:41] <oberhamsi> hannesw, yes it now is
[14:41] <hannesw> very cool!
[14:41] <oberhamsi> statified ajax/json was cooler but this is more practical :)
[14:42] <hannesw> it is
[14:43] <oberhamsi> yep, and jsdoc app is in better shape now.. i'll do some more cleanup.
[14:43] <oberhamsi> tell me if you see something you don't like .. code or htmloutput
[16:30] <hannesw> oberhamsi any reason you pretty much overthrew jsdoc html layout?
[16:31] <oberhamsi> hannesw, more or less by accident when i move the html generation from helpers.js into skins
[16:32] <oberhamsi> could be more dense, but imo better now, no?
[16:32] <hannesw> i liked it better before :)
[16:32] <hannesw> also Class -> Prototype is wrong IMO
[16:32] <oberhamsi> you mean the html source, the tags itself or the layout of the page?
[16:33] <oberhamsi> okay wasn't sure about class, prototype. fixing
[16:33] <hannesw> talking about the layout
[16:34] <oberhamsi> okay, what i changed intentionally: no hierarchies and i changed the overview (top of module) to be more easy to scan
[16:34] <oberhamsi> layout is now easy to change :)
[16:35] <oberhamsi> small stuff i want to add back, like Date.prototype.diff(dateObj) where Date and diff should be bolder
[16:35] <oberhamsi> the hierarchies in overview & leftside i didn't like at all
[16:36] <hannesw> are the changes you did to ringo/webapp still needed? they're still in:
[16:36] <hannesw> http://github.com/oberhamsi/ringojs/compare/47326e4711c136bac1cf0241b6b1a4335712ef98...jsdoc-htmlified#diff-37
[16:36] <hannesw> i agree about the hierarchy in overview - not good
[16:37] <oberhamsi> darn github down for me
[16:38] <oberhamsi> okay, which parts do you not like?
[16:39] <oberhamsi> hannesw, webapp changes are not needed
[16:39] <oberhamsi> (they should not, can't try right now)
[16:39] <hannesw> i don't like the gray frame around the overview section
[16:40] <hannesw> - but wait, it's just me
[16:40] <hannesw> maybe everybody else loves it.
[16:40] <hannesw> so let's wait and see
[16:40] <hannesw> i was just wondering if you made these changes conciously
[16:40] <oberhamsi> we must make it visually clear which part is the overview and where the details start
[16:41] <oberhamsi> yes, those are intentional. that the html source changed was by accident
[16:42] <oberhamsi> maybe gray bg is bad, but that also helped me structure overview per class (the white boxes)
[16:43] <hannesw> i think i'd prefer another approach to that - maybe using different background or marker colors for the "overview" and "detail" headers
[16:43] <hannesw> but yes, i generally prefer the old layout
[16:43] <hannesw> http://nekapuzer.at/ringodocs/stable/core/date/
[16:43] <oberhamsi> hm, heading don't help much in structuring
[16:43] <hannesw> http://ringojs.org/api/master/core/date
[16:44] <hannesw> then maybe a background color just for the overview section
[16:44] <oberhamsi> i agree the gray box is just ugly
[16:44] <hannesw> (what is now white within the gray border
[16:44] <hannesw> )
[16:45] <oberhamsi> okay that could work
[16:46] <earl> oberhamsi: git revert -n bf5d7b01; git revert -n 1f4f48e0; git commit -am 'Revert commits bf5d7b01, 1f4f48e0'
[16:46] <oravecz> i've got a basic portlet written using ringojs rendering in the Liferay portal app
[16:46] <earl> (to try if the webapp changes are still needed)
[16:47] <oberhamsi> earl, thanks!
[16:47] <earl> and `git reset --hard HEAD^` to get rid of the revert if it turns out that the changes are still needed
[16:49] <oravecz_> adding support for poretlets involves creating a new servlet
[16:49] <oravecz_> *portlets
[16:50] <hannesw> oravecz is that liveray.com?
[16:50] <oravecz_> liferay.com
[16:50] <hannesw> right
[16:52] <oravecz> so far I have a RingoJSPortlet.java servlet class that gets the name of a js module using init parameters from portlet.xml
[16:52] <hannesw> are you using liferay for a lot of your projects/products?
[16:52] <oravecz> this is our first one, but it is the basis for all of our future work in this product
[16:53] <oravecz> the nice thing is, because it is a portlet, it will work with any portal
[16:53] <oravecz> The portlet servlet class currently runs preset functions on the ringojs portlet module
[16:54] <oravecz> things like doView, doEdit, doHelp, etc. these are defined by the portlet spec
[16:54] <hannesw> ok, i get it.
[16:54] <oravecz> I am starting now to add a "jsgi=like" js file to act as the servlet's representative in the javascript space
[16:54] <hannesw> is doEdit user-bound or for admins/editors?
[16:55] <oravecz> it can be exposed to clients (users) as well
[16:55] <oravecz> Like the way iGoogle does it
[16:55] <oravecz> so, you could write a weather portlet, and the edit phase would allow users to put in their city or postal code
[16:56] <hannesw> not sure i understand the "servlet's representative in the javascript space" part
[16:56] <oberhamsi> (webapp changes not needed, reverted & pushed)
[16:56] <oravecz> well, like the way jsgi.js works with JsgiServlet
[16:57] <oravecz> So, the controllers don't have to mess with directly writing to the response stream and such
[16:57] <hannesw> ok
[16:57] <hannesw> couldn't jsgi itself do this (i.e. aren't portlets somehow based on servlet api)?
[16:58] <hannesw> actually i'm not sure the current structure of servlet/jsgi interaction has real benefits
[16:58] <oravecz> no, they aren't related
[16:58] <oravecz> I agree with ou to a point
[16:58] <oravecz> it does allow the middleware stack
[16:59] <hannesw> have to check out the portlet api
[16:59] <oravecz> the problems i raised with parsing the HTTP body in jsgi.js comes to light here also. Portlets don't contain an input stream to read from.
[17:00] <oravecz> Only POST and GET are supported, and the Portal acts as an intermediary between the client and the portlet.
[17:00] <oravecz> I'm trying to add this without having to recreate the request/response js objects
[17:03] <earl> can portles have their own URL-space (so to speak)?
[17:03] <earl> if all portlet interaction is done thru do*, you could probably map that to URLs and re-use jsgi directly
[17:04] <earl> i.e. doEdit gets mapped to an jsgi-apps /edit URL
[17:05] <oravecz> they are very different beasts than servlets, for example, any uri's you include in your response have to be created via a function exposed on the response object. The portal handles all communication to the portlet.
[17:06] <oravecz> even the process of submitting a form action is different. First a request/response occurs for all portlets on a portal page, _then_ each portlet gets another request/response to render its view
[17:19] <oravecz> I'm getting this error as I try to write portlet.js (based on jsgi.js)
[17:19] <oravecz> Cannot change the value of attribute "toByteArray" because writable is false. (binary.js#53)
[17:19] <oravecz> Perhaps there is something I am doing wrong to initialize WhinoEngine?
[17:19] <oravecz> *RhinoEngine :)
[17:24] <hannesw> hm, that's usually when you change something in modules/binary.js
[17:25] <hannesw> because properties there are defined as non-writable
[17:25] <oravecz> it is happening in Object.defineProperty
[17:25] <hannesw> but i've also seen this from folks who updated their git repo but didn't run ant jar
[17:25] <oravecz> all i was doing was include('ringo/webapp/util');
[17:25] <hannesw> wait, i'm fixing this
[17:26] <oravecz> it works from JsgiServlet, so i thought it is some param i am not passing to rhino...
[17:28] <thedaian> there's something in the docs about byte arrays being unwrapped when passed into java
[17:29] <ringostarr> 64f4166 Hannes Walln?fer: Define properties as writable in binary module.
[17:29] <hannesw> oravecz that bug should be fixed
[17:29] <hannesw> in ringo master
[17:29] <hannesw> thedaian yes, true
[17:32] <oravecz> was it a bug? wouldn't it of been hapenning every time jsgi.js is created?
[17:35] <hannesw> well no, just that particular error of binary properties being defined as non-writable
[17:38] <oravecz> ok, hey what's the difference in using Object.defineProperty vs. SomeProto.prototype.xxx = function()...?
[17:46] <thedaian> seems like this: "This method allows precise addition to or modification of a property on an object. Normal property addition through assignment creates properties which show up during property enumeration, whose values may be changed, and which may be deleted. This method allows these extra details to be changed from their defaults."
[17:46] <thedaian> from here: https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Object/defineProperty
[17:56] <oravecz> sweet, thx for that
