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

2007-08-01:

[0:00] <jsp> ok. it doesn't have forEach, which was the only HopObject method I tried
[0:01] <jsp> (can you tell I like lambda?)
[0:13] <jsp> hm. presumably it doesn't have forEach 'cause it's a cousin of HopObject instead of a descendant, and HopObject.forEach is defined in core.HopObject, right? so could I put forEach on the Collection? what's its type? Collection?
[0:17] <jsp> (nope, nor OrderedView)
[1:41] <jsp> HopObject.onInit doesn't work as I'd expect, that is, it doesn't seem to get called
[7:35] <zumbrunn> jsp, the collection you get back from hobj.getOrderedView() has no Javascript prototype
[7:35] <zumbrunn> it's not a Javascript object
[7:35] <jsp> :-(
[7:35] <zumbrunn> it's a ListViewWrapper Java class instance
[7:37] <zumbrunn> I'll see about hobj.onInit in a bit
[7:37] <zumbrunn> have to get a coffee first :-)
[7:38] <jsp> I've worked around the onInit thing, but it doesn't seem to get called ever
[8:12] * jerakeen discover's Rhino's 'strict' mode. Shiny.
[8:22] <jsp> what's that?
[8:34] <zumbrunn> jerakeen, how do you enable strict mode?
[8:34] <zumbrunn> I only know the rhino.strictvars property
[8:34] <zumbrunn> http://helma.org/pipermail/helma-user/2006-December/006797.html
[8:34] <zumbrunn> is that what you mean?
[8:35] * zumbrunn is celebrating 716 years of independence today
[8:43] <jerakeen> from http://developer.mozilla.org/en/docs/New_in_Rhino_1.6R6
[12:42] <jsp> congrats, zumbrunn. which country are you in again, and from whom did it become independent?
[12:42] <zumbrunn> http://en.wikipedia.org/wiki/Eidgenossen
[12:44] <jsp> btw, my workaround for the failure of onInit [to do what I expected/wanted anyway] is to store my date object and custom object serialized as # of seconds and a padded string respectively so that I can accurately sort on them but in __propertyname with getters and setters written for propertyname.
[12:45] <zumbrunn> ok, so you wanted to use it as the counterpart for onPersist?
[12:45] <jsp> yes
[12:46] <zumbrunn> for serializing/deserializing, ok
[12:46] <zumbrunn> I'll need that for sure
[12:46] <zumbrunn> (haven't checked yet if I can reproduce the problem)
[12:47] <jsp> I expected that if I set this.created = new Date() with this.onPersist = function(){ this.created = this.created.getTime(); } and this.onInit = function(){ this.created = new Date(this.created); } that basically whenever I tried to use this.created, it would be a Date object
[12:48] <jsp> in fact, it was correctly serialized during the initial saving of the object, but no manner of accessing it seems to invoke the onInit function, so this.created when access in other methods of the object or in the shell is just a #.
[13:21] <jsp> (and congrats again now that I've learned what an Eidgenosse is--though not how to say it)
[13:21] <zumbrunn> hah ;-)
[13:22] <zumbrunn> independence from the roman empire, I guess, btw
[13:22] <zumbrunn> or from what was left of it at the time
[13:27] <jsp> re:ListViewWrapper, Java classes used in JavaScript can also be scripted, though, so it should be possible for me add .forEach to it if only I can find the wiki page or mailing list post (or rhino mailing list post?) that talks about how to do it
[13:28] <zumbrunn> didn't think you could
[13:28] <jsp> iirc it's a relatively recent capability
[13:28] <zumbrunn> does the object you get have a .__proto__ property?
[13:28] <jsp> dunno, hang on. I don't remember if it was done exactly the same way, btw
[13:29] <zumbrunn> of course, we could add forEach to the Java class in question
[13:29] <zumbrunn> but that would only make sense if we also add it to the HopObject prototype
[13:30] <zumbrunn> (and not just as an optional module)
[13:30] <jsp> right. and I want it to match array.forEach
[13:32] <jsp> ok, not very recent: http://helma.org/pipermail/helma-user/2001-September/003865.html
[13:33] <jsp> so what's the full java name of ListViewWrapper (with all the dots)
[13:33] <jsp> ?
[13:35] <zumbrunn> Packages.helma.scripting.rhino.extensions.ListViewWrapper, I believe
[13:48] <zumbrunn> jsp, onPersist and onInit work fie for me
[13:48] <zumbrunn> onPersist = function(){if(this.foo) this.foo = this.foo+2;}
[13:48] <zumbrunn> onInit = function(){if (this.foo)this.foo = this.foo-1;}
[13:49] <jsp> hm
[13:49] <zumbrunn> HopObject.prototype.onInit... that is
[13:50] <jsp> I just defined function onInit in my prototype dir. onPersist worked fine that way, though
[13:50] <zumbrunn> yes, that should be fine
[13:52] <jsp> hm. I guess I'll have to mess with it more later. for now getters/setters are doing the job fine, and I think I may prefer them on balance
[14:00] <jsp> turns out to be Packages.helma.scripting.rhino.ListViewWrapper, but I can't get the class.properties thing to work
[14:03] <jsp> the correct syntax (judging from the email and http://helma.org/docs/guide/properties/class.properties/) is:
[14:03] <jsp> ting.rhino.ListViewWrapper = myListViewWrapper
[14:03] <jsp> helma.scripting.rhino.ListViewWrapper = myListViewWrapper
[14:04] <jsp> (nevermind the first line)
[14:04] <jsp> but so far it doesn't work
[14:19] <zumbrunn> ...and I don't think it will, since class.properties in my understanding works kind of the other way around
[14:20] <zumbrunn> giving you HopObject prototypes that inherit from a Java class
[14:20] <zumbrunn> vs making a Java class inherit from a prototype
[14:26] <jsp> the very old list message clearly says it works the way I want, but reality seems to disagree, so you're probably right
[14:30] <zumbrunn> the problem in this case is probably that the collection object you are after isn't instantiated from within the Javascript environment
[14:34] <zumbrunn> (it's instantiated inside the getOrderedView method, which is Java)
[14:34] <jsp> yup, I got it
[14:36] <jsp> this, however, works: http://helma.pastebin.com/m3b60eda0
[14:37] <zumbrunn> hehe :-) ...isn't Javascript fun?
[14:39] <jsp> all that so I could change this.getOrderedView('__citation').list() to this.getOrderedView('__citation')
[14:41] <zumbrunn> If something in Javascript is wrong, fix it with more Javascript. If you think you can't, add a closure. If that doesn't help, add more closures.
[14:42] <jsp> yup. this one required no closures, though
[15:22] <zumbrunn> so, I've done away with all my property serialization woodoo in the old OpenMocha code
[15:22] <zumbrunn> and was able to replace it with this:
[15:22] <zumbrunn> http://helma.pastebin.com/d7eefb1b4
[15:26] <jsp> looks good
[15:28] <jsp> also, fwiw, when last we were talking about it, you didn't think helma would persist properties with object values directly. but I have confirmed that if you use propname = Object(type) in type.properties (where type is an extended HopObject), Helma will persist that
[15:36] <zumbrunn> so, if you set myhobj.propname = {foo:'bar'} it would store it as a separate HopObject of the type you specfified?
[15:46] <jsp> I don't know about that. but I know myhopobj.propname = new HopObject(); myhopobj.propname.foo = 'bar'; will work
[15:47] <jsp> interesting to know if your version works
[15:47] <zumbrunn> I don't think it does
[15:48] <zumbrunn> but I thought that's what you meant
[15:52] <jsp> it's useful for keeping multiple relations with the built-in db. e.g., if Page has only one Author, you can to author = object(Author) instead of collection()
[15:53] <zumbrunn> yes, good to know
[20:44] <rjb> i've always wondered why html did not provide for client-side includes
[20:45] <rjb> well there are frames (and more recently, iframes), but that's not really what i have in mind
[20:46] <jerakeen> embed JS, use XMLHTTPRequest and pull pages into the dom.
[20:50] <rjb> well yeah, that's a slightly more heavyweight solution
[20:51] <rjb> i know of some ideas revolving around the concept of client-side templating via JS
[20:55] <rjb> but there is no such solution that is mature, complete and easily deployed, to my best knowledge
[20:56] <rjb> it always struck me as weird, that ever since very early versions of html
[20:57] <rjb> you could embed images into your html, referred to by arbitrary urls
[20:57] <rjb> but you could not do the same for fragments of marked up textr
[20:57] <rjb> text even
[21:04] <rjb> (is it possible in helma to define and use macros global to an application?)
[21:10] <rjb> i mean, if i put some macro definitions in Global/macros.js, can i refer to them in skins, and how?
[21:11] <jerakeen> I like trimpath as a client-side templating language. works under rhino too..
[21:18] <rjb> (yes, global macros do work)
[21:18] <rjb> yes i specifically had trimpath in mind
[21:24] <rjb> hmm there is no session.logout() in the reference doc
[21:26] <rjb> but it does of course exist
[22:25] <rjb> well actually this made me think some about the syntax of template languages, whether server- or client-side
[22:27] <rjb> xml has the notions of 'external entities', and 'processing instructions'
[22:32] <zumbrunn> hmm, don't know why session.logout is missing from the docs
[22:33] <zumbrunn> it is documented in the source of the docs
[22:33] <zumbrunn> looks like another JSDoc rendering glitch
[22:39] <jerakeen> rjb: weeeellll, now you point that out. external entities and PIs are a complete _pain_ to deal with
[22:39] <jerakeen> being unable to parse arbitrary documents without a working internet connection is stupid.
[22:46] <jsp> (ah! I was wondering how I was supposed to logout users)
[22:47] <rjb> jerakeen: that's why those notions seem to be mostly ignored
[22:48] <rjb> (although i fail to see how dealing with PIs relates to having a 'net connection)
[22:49] <rjb> but to me, those two notions ought to be the basis of a syntax for templating xhtml
[22:50] <rjb> jsp: i chose to piggyback my user auth on http basic - so effectively, i can't logout a user;-)
[22:50] <rjb> unless (s)he closes the browser that is
[23:03] <rjb> one of the benefits of client-side templates done right would be cache-friendliness

 

 

In the channel now:

Logs by date: