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

2008-07-01:

[1:22] <jkridner|work> back on-line now.
[1:24] <jkridner|work> checked in the code that is actually running (not well).
[1:41] <midnightmonster> you've got two constructors in project.js... that doesn't work/do anything, does it? JavaScript can't pick functions based on number of arguments or anything
[1:43] <midnightmonster> "join project" seems to really mean "create project", no?
[1:47] <midnightmonster> and it seems like skin register_p doesn't actually exist?
[2:10] <midnightmonster> (I know it's a work in progress, just trying to get a feel where you're at)
[5:58] <jkridner> sorry I missed you, but I'm putting some info here in the log, in case you check.
[5:58] <jkridner> yes, "join project" is really "create project".
[5:59] <jkridner> I'm not sure why there are two constructors or what they do. I got some help for this particular feature addition to the website and it was even more a learning project for him (Richard)
[6:05] <zumbrunn> you could establish some conventions that the parent object can rely on
[6:06] <jkridner> like what?
[6:06] <zumbrunn> a pattern that the code in your parent object can follow to access code in child objects
[6:06] <jkridner> sure, but I wouldn't know what type of pattern to create.
[6:07] <jkridner> I'll have to think about that for a while, but I would think other Helma developers would also want to avoid having parents depend on children.
[6:09] <zumbrunn> you could have a convention that the method to add a Child is named using the add prefix followed by the name of the type
[6:09] <zumbrunn> for example addProduct
[6:09] <zumbrunn> and then have a notfound action that checks for that prefix
[6:10] <zumbrunn> and looks up the addProduct method in the Product prototype
[6:10] <jkridner> oh, I didn't think about putting it into 'notfound'.
[6:11] <jkridner> so, create_type could look for an object 'type' and call the 'create' to get the first object of that type?
[6:11] <jkridner> (I don't think I'm quite awake enough.)
[6:12] <zumbrunn> why "first object"?
[6:14] <jkridner> well, the way I want to structure my objects is to have http://site/<parent>/<child> displays the child contents and http://<parent> shows the list of children, if <parent> has a name that associates to the type of children objects.
[6:15] <jkridner> I was actually hoping to put into <parent> a bit of content in the object itself to say that it has children that need listing, in order to put the list into a certain part of the body.
[6:16] <zumbrunn> ok, so you have a prototype called Parent and one called Child, right?
[6:16] <jkridner> essentially, I'm taking something like "Page" and I want to add additional properties for certain sets of sub-pages.
[6:16] <jkridner> right.
[6:16] <zumbrunn> and you want to avoid putting Child related code in Parent
[6:17] <zumbrunn> but you want Parent to list Child objects
[6:17] <zumbrunn> and you want Parent to be able to serve an addChild action
[6:17] <jkridner> right, but only one specific parent instance.
[6:17] <zumbrunn> oh
[6:17] <zumbrunn> not the prototype, just that object
[6:17] <jkridner> and, I don't really care what type that particular Parent is...
[6:18] <jkridner> correct, just the one object.
[6:18] <zumbrunn> hehe, that sounds a bit like what jhino does
[6:18] <jkridner> in fact, I'd prefer for that one object to become a bit of a prototype for the Children.
[6:18] <jkridner> what is jhino?
[6:18] <zumbrunn> http://code.google.com/p/e4xd/downloads/list
[6:19] <zumbrunn> I kind of got stuck with that because I'm rethinking how this would all apply to helma-ng
[6:20] <zumbrunn> (the current openmocha code is for Helma 1)
[6:21] <zumbrunn> with jhino you can modify properties of individual object instances to override behavior that would otherwise be inherited from the prototype chain
[6:22] <zumbrunn> (or specify any additional custom behavior)
[6:22] <zumbrunn> it basically adds a hierarchical inheritance to the prototype inheritance
[6:23] <jkridner> sounds close.
[6:23] <zumbrunn> well, there are many ways to go about that
[6:24] <jkridner> I would ideally like to be able to build forms in something like a "Page" (concept borrowed from the wiki-like implementations with Helma).
[6:24] <jkridner> even more ideally, the elements would get encoded directly into (x)HTML with RDFa mark-up.
[6:25] <zumbrunn> sounds good
[6:25] <jkridner> for example, I want my Project list to be hDOAP (or similarly) encoded.
[6:27] <jkridner> so, I should learn jhino for this?
[6:27] <zumbrunn> no, I'm not saying that
[6:28] <zumbrunn> but feel free to spy and steel if you feel there is something to spy and steel from
[6:29] <zumbrunn> jhino might be a bit to crazy and unfinished to really make worth thinking yourself into
[6:29] <zumbrunn> but your welcome to do so, of course
[6:29] <zumbrunn> I could use another brain, since mine is definitely not sufficent
[6:30] <jkridner> well, I am looking to get something functional within the not-too-distant future.
[6:30] <jkridner> I really need to find some funding to get some help. :)
[6:30] <zumbrunn> :-)
[6:31] <jkridner> if I were to have coded the
[6:31] <jkridner> if I were to have coded the "create project" additions to the site...
[6:31] <jkridner> I would have just made each project a "Page".
[6:31] <jkridner> having hierarchy among Page objects is easy.
[6:32] <jkridner> then, I just need to have a macro that lists children and some way to invoke that within the body of the Page.
[6:34] <jkridner> one thing that was holding me up was <form>s that overlapped.
[6:34] <zumbrunn> overlapped?
[6:34] <jkridner> I had a form in the skin and a form in the body.
[6:34] <jkridner> the one in the body closed the one in the skin, instead of its own.
[6:35] <jkridner> (cannot nest forms)
[6:35] <jkridner> I need to go back and look at that, because it seems like it should be easy to avoid, but I had a hard time with it a couple of months ago.
[6:35] <zumbrunn> aha
[6:35] <zumbrunn> sounds messy
[11:03] <hypersmil> http://helma.zumbrunn.com/reference/String.html
[11:03] <hypersmil> the description of the repeat method is wrong
[17:45] <zumbrunn> thanks hypersmil, fixed
[20:35] <decke> zumbrunn: and how does the new JSDT in eclipse feel?
[22:14] <midnightmonster> so some poor man's profiling of my application indicates that the ~1.5 second load time of my large tables (34 cols x 220 rows) is all but 50 msec in the E4X obj generation and outputting (including ~200 msec for some vanity post-processing of the XML string). That's taking out most of the output, so presumably if I were just outputting text some time still would get used up, but it's hard to believe it would be more tha
[22:15] <midnightmonster> apparently it's possible to use a different XML impl (via JAXP?) for your app and hence for E4X. anyone know how to do this? I want to see if there are any that would be faster.
[23:00] <midnightmonster> I'm not 100% sure, but I think I succeeded in replacing JAXP 1.3 with 1.4.2
[23:01] <midnightmonster> it may be a touch faster

 

 

In the channel now:

Logs by date: