2007-10-23:
[3:14] <midnightmonster> baggles, bslivka pretty much gave you the straight dope already, but I'd add that no, Helma does not have any facility to automatically do its mapping with foreign keys or otherwise. you have to configure which prototypes manifest which tables anyway, so foreign key stuff ends up not being much more work.[3:25] <midnightmonster> actually... I think I've heard a few times of a standard an add-on that does some prototype generation for you from the schema, but I don't know where it is or whether it make use of foreign keys. (zumbrunn?)[10:50] <zumbrunn> regarding alternative approaches to the default type.properties centric o/r mapping...[10:50] <zumbrunn> I'm aware of three more or less experimental directions[10:50] <zumbrunn> the sqlshell, rabbit and warp[10:51] <baggles> hum. well, it's a toss-up for me between trying a common-lisp server and some kidn of javascript-based one.[10:51] <zumbrunn> the sqlshell allows you to generate type.property files from a schema[10:51] <zumbrunn> http://helma.zumbrunn.net/tools/about_sqlshell[10:51] <baggles> is there much/any possibility for using the DOM on server-side aswell?[10:52] <zumbrunn> rabbit (and rocket the super rabbit) are code centric[10:52] <baggles> hum. interesting, i guess.[10:52] <baggles> i think i got used to the total reflectivity of rails.[10:52] <zumbrunn> and warp automatically does the mapping to helma objects from a db[10:52] <baggles> well, of ActiveRecord anyway.[10:53] <zumbrunn> http://dev.helma.org/wiki/Rabbit/[10:53] <zumbrunn> http://helma.org/pipermail/helma-dev/2007-May/003571.html[10:54] <baggles> hum. warp looks a bit more promising.[10:54] <zumbrunn> http://helma.org/pipermail/helma-user/2007-July/007068.html[10:55] <zumbrunn> http://helma.org/pipermail/helma-user/2007-July/007070.html[10:59] <baggles> thanks[13:52] <e__> hello[13:54] <zumbrunn> hi e__[14:01] <e__> i thought we should display the full sql statement if an sql exception is thrown[14:02] <e__> but i think i will tell this hannes directly[14:07] <zumbrunn> or just file a bug for it[14:08] <zumbrunn> http://helma.org/bugs/ seems to be down, though ...hmm[14:12] <zumbrunn> ok, it's back[14:25] <e__> other issue[14:27] <e__> i have a function and a assign the return value of this function to a property in req.data[14:27] <e__> but if this property is already set this does not work[14:27] <e__> if the function returns null[14:30] <zumbrunn> works for me[14:31] <zumbrunn> http://helma.pastebin.com/d1fd3d745[14:31] <zumbrunn> I get bar+undefined[14:32] <e__> hm[14:49] <e__> maybe it's because the variable is set from helma outside and not inside[14:52] <zumbrunn> outside and not inside?[14:59] <e__> it's set via get request[14:59] <e__> and then i want to reset it[14:59] <zumbrunn> oh, could be[15:00] <e__> but maybe i have do delete it before[15:03] <zumbrunn> I can override the value even if it was set using GET or POST[15:04] <e__> hm and i can't even delete it[15:04] <zumbrunn> but not to null, like you said[15:04] <e__> yes i can override too, but i can't set it do null[15:05] <e__> or delete it[15:05] <zumbrunn> the original POST/GET values probably live kind of in a different scope[15:06] <zumbrunn> so, if req.data.foo is set to null, the original GET value is "inherited"[15:06] <e__> hm maybe i have to ask hannes too for this issue[15:06] <e__> hm thats bad, cause how can i delete it[15:08] <zumbrunn> setting it to an empty string wouldn't work for what you need to achieve?[15:08] <e__> hm that may work[15:09] <e__> yup works for me :)[15:09] <zumbrunn> :-)[15:09] <e__> thanks a lot[18:48] <drbobb> hmm the guys @mozilla.org just fixed 2 rhino bugs i'd reported[18:48] <midnightmonster> spiffy. what were they?[18:50] <drbobb> https://bugzilla.mozilla.org/show_bug.cgi?id=396700[18:50] <drbobb> https://bugzilla.mozilla.org/show_bug.cgi?id=397882[18:52] <midnightmonster> good catches. since I've been eating up every bit of functional programming that gets dropped into javascript, I probably would have been bit by those at some point[18:54] <midnightmonster> in the category of little things you learn much later than it seems you ought, I just figured out this short/fast as possible syntax for a for-loop over array-like things:[18:54] <midnightmonster> for(var i=list.length; i--;) { whatever }[18:55] <midnightmonster> (if your client was stupid like mine and inserted a smiley, that was supposed to be "i--; )"[18:56] <midnightmonster> obviously that goes through the list backward, so you can't use it if going fwd matters.[18:57] <drbobb> var n=list.length; while ( --n ){}[18:57] <drbobb> uh sorry[18:57] <midnightmonster> n--[18:58] <drbobb> that should be[18:58] <drbobb> while ( --n >= 0 ){}[18:59] <drbobb> which is the same as while(n--) {}[18:59] <midnightmonster> var n=list.length; while(n--){} <-- done right, yours is one char longer than mine.[19:02] <drbobb> i tend to use more spaces;)[19:08] <drbobb> and it is said that --n is slightly faster than n--[19:08] <drbobb> but i doubt whether one would be able to measure the difference[19:09] <midnightmonster> it is in PHP. don't know if it is in JavaScript[19:11] <midnightmonster> I like for better than while there b/c I want it all on one line. and of course you could put all yours on one line, but then it's not obvious at the beginning of the line that it's a loop. counting up with the for loop you need another line/var to store whatever.length in to save the double lookup on every iteration, so that[19:11] <midnightmonster> 's why I like the form I recently figured out[19:12] <midnightmonster> bbl
In the channel now:
Logs by date: