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

2007-07-30:

[9:56] <rafsoaken> hi
[9:57] <zumbrunn> hi rafsoaken
[16:31] <jsp> chris, inspired by your code, I wrote HopObject.childNames() which returns an array of all the names (accessname) of the children of HopObject (or anything that extends it).
[16:31] <jsp> HopObject.prototype.childNames = function(accessname) {
[16:31] <jsp> var proto = this; var type;
[16:31] <jsp> while(!accessname && (proto=proto.__proto__)!=Object.prototype) {
[16:31] <jsp> if(type = / (\w+)\]$/(proto.toString())[1])
[16:31] <jsp> accessname = app.getPrototype(type).getTypeProperties().getProperty("_children.accessname");
[16:31] <jsp> }
[16:31] <jsp> if(!accessname) return null;
[16:31] <jsp> a = [];
[16:31] <jsp> this.forEach(function(c) { a.push(c[accessname]); });
[16:31] <jsp> return a;
[16:31] <jsp> }
[16:34] <zumbrunn> damn... we really need a pastebin :-)
[16:36] <rjb> http://pastebin.ca/
[16:39] <jsp> hm. we need a pastebin that has a more helpful/reasonable IP policy
[16:39] <jsp> "Keep in mind that any posts to the public pastebin (http://pastebin.ca/) are considered to be placed into the public domain."
[16:40] <zumbrunn> hmm
[16:42] <jsp> If it were true that things could unequivocally be placed in the public domain just by putting them in the pastebin, that would be helpful to some people since at least they would have some free code. but since I doubt that would stand up in court, the situation is actually that you don't know if/how you can use anything there, not even considering the problem of people posting others' code.
[16:44] <zumbrunn> yes, some would even argue that you can't place something in the public domain at all
[16:44] <rjb> well sure you can't, unless you own it
[16:44] <zumbrunn> some would argue you can't, even if you own it
[16:45] <zumbrunn> that you can't strip yourself from your copyright
[16:45] <rjb> i don't know that argument
[16:45] <rjb> but it might depend on where you live, and your local legal system
[16:46] <zumbrunn> international copyright rules knows no such thing as public domain
[16:46] <jsp> right. that's US-and-some-other-places
[16:47] <zumbrunn> copyrights expire, but you can't choose to "expire them early"
[16:47] * rjb pleads ignorance
[16:48] <jsp> 'point is, it's a very unhelpful policy to have on one's pastebin
[16:48] <zumbrunn> well, I'm not saying I would side with that argument either...
[16:48] <zumbrunn> just saying some would :-)
[16:51] <rjb> most likely that policy statement lacks any legal value, and is of no consequence anyway
[16:56] <jsp> http://helma.pastebin.com/m5eb7cbce
[17:12] <jsp> I have pleased the hopbot.
[17:12] <jsp> and I didn't even have to sacrifice a chicken
[17:12] <zumbrunn> yep :-)
[17:17] <rjb> ok, so i don't know what _children.updateable = true does after all
[17:17] <rjb> (in type.properties)
[17:17] <jsp> makes it so you can use HopObject.update() is my understanding
[17:17] <jsp> (provided that your data source meets the other criteria)
[17:18] <rjb> hmm
[17:20] <rjb> my root's _children seem to meet those conditions
[17:20] <jsp> hopbot's feeling fickle
[17:21] <rjb> but when i call root.update() in a shell, an exception is thrown
[17:21] <jsp> lurvely
[17:21] <jsp> what's the exception?
[17:22] <rjb> ava.lang.RuntimeException: Error retrieving NodeIDs
[17:22] <rjb> java. ...
[17:23] <rjb> how cute
[17:30] <jsp> anyway, it sounds like there's a helma error or your data source doesn't meet the requirements or is otherwise unavailable for some reason
[17:30] <jsp> but I've no direct experience
[17:30] <rjb> the data source is working just fine
[17:33] <jsp> the description of .update says "updateable subnode-collections"--plural. could it be trying to update some other more recently added collection in root and screwing up? 'cause this worked before, right?
[17:34] <rjb> yes there is another collection
[17:34] <rjb> but it was always there, and has no properties declared
[17:34] <jsp> did .update() used to work?
[17:35] <rjb> i never called it before
[17:35] <jsp> oh.
[17:35] <jsp> try unmapping the other collection temporarily?
[17:36] <rjb> for the other collection, i'm using the built-in helma persistence
[17:41] <jsp> unrelated: what kind of formatting string does Date.format use?
[17:48] <rjb> no idea
[17:56] <jsp> same as described at http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html , apparently
[17:57] <jsp> zumbrunn, is there yet a place where I can add useful information to the documentation such as that? (I suppose the answer there was obvious to Java converts, but it's totally opaque to others.)
[18:17] <rjb> how weird
[18:17] <rjb> seems that when i call root.update()
[18:18] <rjb> helma tries to look up 'update' in my mysql database
[18:18] <rjb> or something
[18:18] <jsp> well, that's nice and weird
[18:18] <rjb> and that's why an exception is thrown
[18:19] <rjb> [ERROR] Error retrieving Node "update" from HopObject root
[18:19] <rjb> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'update' at line 1
[18:19] <jsp> would be nice to know the whole query
[18:19] <jsp> wonder if mysql is logging them?
[18:19] <rjb> i don't think so
[18:20] <rjb> mysql usually logs only queries that modify data
[18:20] <jsp> (not also errors?) perhaps you could configure it to log all for debugging
[18:20] <rjb> it's probably trying to look up a row with id=update
[18:21] <zumbrunn> jsp, for fixes/improvements that concern the reference (like this date format issue for example), this channel or the mailing list would be the right place to mention it and I'll then have to commit it in cvs for now
[18:21] <zumbrunn> for other contributions to the user guide, just add pages to the wiki
[18:21] <jsp> ok. then please add a link to the date format documentation :-)
[18:21] <zumbrunn> we can then rearrange that content as it accumulates
[18:22] <zumbrunn> yep :-)
[18:23] <rjb> .. which would explain the syntax error (update being a reserved word)
[18:23] <rjb> but otherwise it makes no sense at all
[18:23] <jsp> but it doesn't make any sense why it would query... yeah
[18:23] <rjb> it should at least write id='update' (with quotes)
[18:23] <rjb> that wouldn't throw
[18:23] <jsp> but it doesn't make sense that it would be doing that at all
[18:24] <jsp> tech/TeX--your alter ego has switched from Ruby to typesetting?
[18:25] <jsp> (tech, also, your site seems to be down)
[18:27] <jsp> chris, do you have cvs access for helma or just the docs? 'cause last I checked hannes hadn't got round to checking in an updated rhino, and it would be nice to have it there so people can get it from an official-type source.
[18:53] <zumbrunn> jsp, I didn't commit the rhino.jar containing the e4x fix because I did not review the other diffs it contains
[18:53] <zumbrunn> don't want to introduce a buf that bites people while fixing one that doesn't
[18:54] <zumbrunn> (because "nobody" in helma land uses e4x yet)
[18:54] <jsp> I do hate biting bufs
[18:54] <jsp> (I know--very sad)
[18:55] <jsp> (here I am on a totally niche framework trying to promote the best feature no one's ever heard of)
[18:56] <jsp> ("one is the loneliest number, one is...")
[18:56] <zumbrunn> well, I declared my love for it a while ago...
[18:56] <zumbrunn> http://zumbrunn.com/mochazone/I+love+E4X/
[18:57] <jsp> ("two can be as bad as one: it's the loneliest number but the number one")
[18:57] <zumbrunn> hehe
[18:58] <jsp> what're you doing with all the %% %% stuff?
[18:58] <jsp> did value/attribute literals not work then or did you not know of them?
[18:59] <jsp> (templates have to be functions instead of variables, but I think it's worth it)
[19:00] <zumbrunn> those are parsed out by the render function
[19:00] <jsp> right--I got that
[19:01] <jsp> I guess if you want to implement loops, etc in a separate language you still need that
[19:01] <zumbrunn> yes, but I definitely didn't know e4x well yet back then
[19:01] <zumbrunn> there are better ways of doing what I tried to do
[19:02] <zumbrunn> I'll have to think that through again one of these days
[19:03] <jsp> I've said goodbye to template lanuages
[19:06] <jsp> I think we (i.e., everyone) came up with those b/c our programming languages sucked for writing markup. suddenly, JavaScript is the only language in the world that *doesn't* suck for producing and handling markup. I think it changes the game.
[19:12] <rjb> still having problems with root.update()..
[19:12] <rjb> if i call it from an action (instead of from a shell)
[19:13] <rjb> i still get an exception, but a different one
[19:13] <rjb> java.lang.RuntimeException: unable to update SubnodeList not marked as updateable (_children)
[19:13] <jsp> but I take it _children.updateable = true is set
[19:15] <rjb> rigt
[19:15] <rjb> right, even
[19:16] <rjb> in Root/type.properties
[19:19] <jsp> beats me. seems like your code is *special*
[19:20] <rjb> you find no problem calling root.update()?
[19:20] <jsp> I don't use it. I don't have any projects setup atm that use external dbs
[19:21] <rjb> you use the builtin persistence layer only?
[19:21] <jsp> so far.
[19:22] <rjb> i thought you were using h2
[19:22] <rjb> but it must have been someone else
[19:22] <jsp> no, it was me that suggested it, and I've tried it, and I may likely use it in the future, but I'm still only on my first real project, and I decided to try with just the built-in
[19:22] <rjb> btw i discovered an easy way to crash an h2 database :(
[19:22] <jsp> ?
[19:23] <rjb> but i heard form the author, he says he'll release a fix soon
[19:23] <rjb> form -> from
[19:23] <jsp> as in "select * form mytable"?
[19:24] <rjb> noo
[19:24] <jsp> oh
[19:24] <jsp> right
[19:24] <jsp> what was the crash bug?
[19:25] <rjb> update more rows at a time than fit in the in-memory undo log
[19:25] <rjb> (as far as i understand)
[19:25] <jsp> hm. that seems bad
[19:25] <rjb> no surprise that it fails, but it also corrupts the database
[19:25] <jsp> yeah, that's bad
[19:25] <rjb> and you can no longer read from your table(s)
[19:32] <rjb> anyway, i'm approaching the conclusion that helma won't really be my favorite solution
[19:33] <rjb> i don't mind getting my hands dirty with sql
[19:33] <jsp> *nods* if you're encountering bugs that keep you from working, yeah. that'd be a pain
[19:34] <rjb> i think i'd rather have more direct control over the dbms coupling
[19:34] <jsp> and if you like to write sql, Helma in its current state isn't very optimal--the direct DB access stuff is really primitive
[19:34] <zumbrunn> what's missing there?
[19:36] <jsp> two things at least present in every other competent DB-connecting lib: 1) the ability to process results one at a time so as not to explode one's memory and 2) prepared/parameterized statements
[19:37] <zumbrunn> surely, anything that is missing must be available in Java, right?
[19:37] <rjb> i work around 1 by applying limit clauses
[19:37] <jsp> yeah, it is
[19:37] <zumbrunn> so we should be able to wrap it in Javascript
[19:38] <jsp> yes, could be done. should be.
[19:38] <jsp> but I haven't worked on it yet myself b/c my java-fu is extremely weak and I don't need it myself yet
[19:39] <jsp> rjb, yeah--they certainly can be worked around, but it's a pain.
[19:39] <jsp> (not that I have to tell you that)
[19:41] <zumbrunn> the way I see it, there are two "helmas"... a flexible javascript environment that allows everybody to do things the way they prefer... and a framework that evolves based on a general consensus of best practices
[19:42] <rjb> it's not such a great pain most of the time
[19:44] <rjb> and 2) is mostly a matter of convenience
[19:44] <jsp> true that. probably true of many things. I'd love to see people forget templates and/or at least build templating atop e4x, but I'm not leaving if I don't get my way. OTOH, the DB interface is simply poor ATM. There's no reasonable argument in favor of it's current state beyond "we haven't got to improving it yet".
[19:45] <jsp> I think (2) is a big deal, b/c when the easiest thing is not the right/safe thing, the wrong/unsafe thing will get done an awful lot. (example: see PHP)
[19:45] <jsp> true that... was re: zumbrunn, I think... was re: rjb
[19:45] <zumbrunn> yeah, got that :-)
[19:46] <rjb> ok, you mean implement automatic safeguards against sql injection
[19:47] <jsp> that's what I see as the principle importance of parameterized statements. that may be colored by my PHP background in which SQL injection features so prominently
[19:48] <zumbrunn> jsp, I don't remember... did you bring this up on the mailing list?
[19:48] <zumbrunn> (re: parameterized statements and SQL injection)
[19:49] <zumbrunn> If not, you probably should
[19:50] <jsp> no. I helped someone with the results-returned-as-giant-array problem (1) on the list, but I talked about (2) here before
[19:50] <zumbrunn> yes, I remember that
[19:51] <jsp> http://helma.zumbrunn.net/hopbot/2007-07-13
[19:52] <rjb> my one-time fave scripting language, Pike, implemented this sort of safeguard
[19:52] <rjb> by having a sprintf-like method for building sql queries
[19:53] <jsp> yeah--similar effect. nearly all db engines support it natively, though, too.
[19:54] <rjb> that was before mysql supported prepared statements
[19:54] <jsp> and even now there's a penalty in MySQL for using them
[19:54] <jsp> PDO in PHP works around that very effectively, though
[20:13] <zumbrunn> jsp, regarding building templates atop e4x...
[20:13] <zumbrunn> I'm rewriting Openmocha and am wrapping skins in e4x objects...
[20:13] <zumbrunn> http://helma.pastebin.com/m1dd9a0b7
[20:15] <jsp> cool
[20:16] <zumbrunn> so, you can do res.write(this.views.mye4xtemplate)
[20:18] <zumbrunn> (that's what I needed getPrototypeChainAsNames for, a few days ago)
[20:22] <jsp> is there a reason to do line 13-15 as you did instead of
[20:22] <jsp> views.__defineGetter__(skin,function(){ return new XML(path[path.length-1].renderSkinAsString(skin)); }); ?
[20:23] <zumbrunn> the context of "skin"
[20:24] <jsp> closure
[20:24] <jsp> takes care of that
[20:24] <zumbrunn> don't think it did
[20:25] <jsp> (afaik, the closures are there anyway, so you may as well use them. plus your version barfs in the unlikely event that a skin name contains a double quote. actually I don't know if that's possible)
[20:25] <jsp> (hmmm. actually the closure might nor work as desired there. must test)
[20:29] <jsp> yeah, you're right. skin would still be available, but would be set to its last value.
[20:32] <zumbrunn> another problem was passing in the context of "this"
[20:32] <zumbrunn> this..getPrototypeChainAsNames() worked fine
[20:32] <zumbrunn> but how to get that into the context of renderSkinAsString
[20:33] <jsp> call
[20:33] <jsp> hang on
[20:34] <jsp> where does path come from?
[20:34] <zumbrunn> it's passed into the getter when this.views is called
[20:35] <jsp> getters don't have arguments, so I'm confused
[20:36] <jsp> or is it a built-in like the arguments pseudo-array?
[20:36] <zumbrunn> no, not as an argument
[20:36] <zumbrunn> just as "this" :-)
[20:39] <zumbrunn> Mocha == HopObject ...in case that's where the confusion comes from
[20:40] <jsp> I'm ok with Mocha==HopObject... still don't get what defines path.
[20:40] <jsp> oh!
[20:40] <jsp> it's in global
[20:40] <jsp> i hadn't seen that before
[20:45] <jsp> you can do this:
[20:45] <jsp> that = this;
[20:45] <jsp> views.__defineGetter__(skin,function(){ var s = skin; var obj = that; return function(){ return new XML(obj.renderSkinAsString(s)); }; }());
[20:47] <jsp> http://helma.pastebin.com/m101ff68b
[21:07] <jsp> apparently in Helma Array.reduce() exists but doesn't behave correctly
[21:38] <rjb> wtf??
[21:38] <jsp> ?
[21:39] <jsp> mine or something more dramatic?
[21:39] <rjb> now helma fails to serve my css file from /static/
[21:39] <rjb> java.lang.RuntimeException: Error retrieving Node
[21:39] <rjb> Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Unknown column 'static' in 'where clause'
[21:39] <rjb> now this is getting seriously weird
[21:39] <jsp> there's something screwy going on there
[21:40] <jsp> restart helma?
[21:40] <rjb> hmm
[21:42] <rjb> didn't help
[21:43] <rjb> [ERROR] Error retrieving Node "static" from HopObject root
[21:43] <jsp> it seems like it has lost the whole mounting of static files thing
[21:43] <jsp> double-check your apps.properties?
[21:44] <rjb> hmm happens only on some requests
[21:45] <rjb> intermittently
[21:45] <jsp> could it be that rebooting did fix but you're seeing cached responses sometimes?
[21:49] <rjb> nope. i made an edit to the css and reloaded
[21:49] <rjb> browser sees the change
[21:51] <jsp> browser cache usage behavior isn't always obvious. I'd dump the cache and then try to reproduce
[21:54] <rjb> no i can verify it's up to date
[21:54] <jsp> (dang--helma has its own method Object.reduce() that recursively turns HopObjects into normal objects, but it operates on Arrays and standard Objects, too, presumably to recurse through them and modify their children. JavaScript 1.8 has Array.reduce(), which is the functional programming-style thing in the same family as map and filter.)
[21:54] <rjb> i can view the actual source of the css in mozilla
[21:55] <jsp> I know. but when you're viewing the CSS on this same, do you sometimes still get the problem?
[21:58] <rjb> well i haven't been able to trigger it again for a while
[22:00] <rjb> heh one of a couple of weird behaviors i've seen on helma
[22:00] <rjb> i have yet to solve the puzzle of the appended null bytes
[22:00] <jsp> I just had one with the shell, but it turns out it was b/c I overwrote array.reduce
[22:03] <rjb> the only thing i'm doing that could be called tricky by any stretch
[22:03] <rjb> is reaching into the db bypassing helma's orm
[22:08] <zumbrunn> jsp, obj.reduce() is in modules/core/Object.js
[22:08] <zumbrunn> it's not part of helma core
[22:09] <jsp> shell uses it, though
[22:09] <zumbrunn> no, probably the inspector does
[22:09] <zumbrunn> we should change that
[22:10] <rjb> well the basic view of my app is pretty much functional
[22:10] <rjb> barring further mysterious glitches
[22:10] <zumbrunn> like I said yesterday already, the helmaTools really are intended to be implemented in a way that should not interfer with anything else
[22:10] <rjb> http://bobo.fuw.edu.pl/fotw/
[22:11] <jsp> I'm not knowingly using the inspector, but something that comes up while I'm using /shell uses it, b/c part of it barfs when I overwrite it with the functional-style reduce
[22:11] <zumbrunn> I think it's only the inspector that currently doesn't stick to that
[22:11] <zumbrunn> because it is part of helmaTools, it loads
[22:11] <zumbrunn> that's enough
[22:12] <jsp> ok.
[22:12] <zumbrunn> anyway, the current Rhino doesn't have Array.reduce() yet, or does it?
[22:13] <jsp> no. but as usual, mozilla provides an implementation, and I wanted to use it
[22:13] <zumbrunn> you can't?
[22:14] <jsp> I can. It just made errors appear in the shell
[22:14] <jsp> once I called it fold instead of reduce, everyone was happy
[22:15] <zumbrunn> ok, I'll see if we can clean out the dependencies from the inspector code
[22:16] <jsp> seeing as reduce is presumably coming (eventually) to Rhino, and it's the obvious cousin to map and filter, maybe it should be renamed and the old name deprecated but kept around for a while?
[22:17] <zumbrunn> yes
[22:18] <jerakeen> is it legitimate to be slighlty freaked out by new language features wandering in and stomping existing methods?
[22:19] <jsp> has the potential to happen anywhere you can extend built-in objects
[22:19] <zumbrunn> actually, I'm not sure why it would get in the way of array.reduce()
[22:19] <jsp> it shouldn't except that it seems meant to act recursively on arrays to call .reduce() on each of their children
[22:21] <jsp> or maybe not. I can't now duplicate the problem I was having
[22:21] <jsp> maybe I confused the shell in some other way
[22:28] <jsp> yeah---nevermind about the reduce problem. it is put on Object instead of HopObject, which seems like a mistake, but overloading it on Array doesn't seem to be a problem
[22:32] <jsp> jerakeen, actually new methods being added to the language won't usually clobber ones that your code (or Helma's) adds. Instead, Helma's or yours will clobber the new ones and you'll never see them. Except in an odd case like this. In this case one of Helma's optional add-ons defined .reduce on Object, so everything that extends Object gets it (which is basically everything), which was probably wrong to do since AFAICT only HopObject
[22:33] <jsp> rjb, looks like a nice little link collection. did you upgrade to helma 1.6 or still with 1.5?
[22:33] <rjb> still with 1.5
[22:33] <zumbrunn> but that's what doesn't make sense (re: obj.reduce)
[22:33] <rjb> i need to upgrade the jvm as well to work with 1.6, so i postponed it
[22:33] <zumbrunn> that shouldn't effect Array.reduce
[22:35] <jsp> It wouldn't if Rhino defined it or now that I've done it, but it would otherwise since Array inherits from Object
[22:35] <zumbrunn> not if array defines it's own it wouldn't
[22:35] <jerakeen> I'm too used to perl. It's nice and dead, ad noone goes and adds keywords when you're not looking.
[22:36] <jsp> right. that's what I said, z
[22:39] <jsp> jerakeen, heh--these aren't keywords being added, though--just more methods on existing objects.
[22:42] <jsp> not even as bad as PHP where they add new top level functions most point releases.
[23:02] <rjb> argh
[23:03] <rjb> there we go again
[23:03] <rjb> something is wrong
[23:03] <jsp> css again?
[23:03] <rjb> i added a *.hac file to my Root/ and wrote some code into it
[23:04] <rjb> but again, instead of using it helma seems to be querying the database for a row with id of add
[23:04] <rjb> with id = the action name, i mean
[23:05] <jsp> I wonder if that's a consequence of _children.updateable
[23:07] <rjb> ok i restarted the app from 'manage'
[23:08] <rjb> i use the showAPI function in manage, and my new action is there indeed
[23:08] <rjb> but requesting it does not work
[23:09] <jsp> ooh. I managed to do that too
[23:09] <jsp> but it wasn't a db thing, it was a e4x syntax errir
[23:09] <jsp> error
[23:12] <rjb> i can even look at the source code of my new action in manage
[23:12] <jsp> (same was true for me)
[23:12] <rjb> but i can't request it
[23:12] <rjb> wtf??
[23:12] <jsp> I suspect an error in the hac
[23:12] <jsp> can you pastebin the code?
[23:12] <rjb> syntax errors show up in logs
[23:13] <jsp> they should. except when they don't
[23:13] <jsp> like mine
[23:13] <jsp> I'm just saying--it happened to me. It's worth checking.
[23:15] <jsp> (e4x specifically is in a weird twilight between parsing and executing so that you won't see some errors in it when you expect)
[23:16] <rjb> the code is totally trivial
[23:18] <zumbrunn> rjb, can you use the shell action to check if your method is there?
[23:19] <rjb> rebooted helma - no change..
[23:21] <rjb> zumbrunn: you mean?
[23:21] <rjb> i typed root.add(); into the run script textarea
[23:21] <zumbrunn> do you use the helmaTools?
[23:21] <rjb> aaaa
[23:22] <zumbrunn> (include that repository in your app)
[23:22] <rjb> add is a special identifier, isn't it?
[23:22] <zumbrunn> then go to /shell using the browser
[23:22] <rjb> yeah right i did all that
[23:22] <jsp> (no--add isn't magic. I have a couple)
[23:22] <rjb> root.add
[23:23] <rjb> that might be the problem
[23:23] <jsp> is a method, that's true...
[23:23] <zumbrunn> Root.prototype.add_action
[23:23] <zumbrunn> is that defined?
[23:24] <jsp> in 1.6, anyway, that doesn't keep /add from working, b/c, like z just said, hac's get transformed into _action
[23:25] <zumbrunn> (that's not 1.6 specific)
[23:25] <jsp> (I figured not)
[23:26] <rjb> anyway changing the name does not help
[23:27] <zumbrunn> how is the add action defined?
[23:27] <zumbrunn> do you have a file called add.hac?
[23:27] <rjb> right
[23:27] <zumbrunn> or a function called add_action?
[23:27] <rjb> Root/add.hsc
[23:27] <rjb> Root/add.hac
[23:27] <jsp> take all the code from the .hac file and paste it into the shell textbox and run
[23:28] <zumbrunn> if you do "Root.prototype.add_action" in the shell, do you see the source code that's inside your add.hac file?
[23:31] <rjb> wait a min.
[23:31] <rjb> running the code in shell returns true - no errors in the code
[23:33] <rjb> zumbrunn: affirmative
[23:33] <zumbrunn> what about "Root.prototype.add_action"?
[23:33] <rjb> except i call it create_action now
[23:33] <zumbrunn> ok
[23:33] <rjb> but yes shell does show me the code of the definition
[23:34] <zumbrunn> then I would say it must be something goofy in your type.properties
[23:34] <rjb> what's more, no more errors are being logged
[23:35] <rjb> since i restarted helma
[23:36] <rjb> ok i threw out the _children.updateable
[23:36] <rjb> no change
[23:39] <rjb> ok, i created a Root/test.hac, containing:
[23:39] <rjb> res.write("<html><head><title>test</title></head><body>this is a test.</body></html>");
[23:39] <rjb> the result is as expected, it works
[23:39] <rjb> Root/create.hac still does not
[23:41] <zumbrunn> what if you put the code inside of create.hac into test.hac
[23:44] <rjb> hmm i put a line
[23:44] <rjb> res.write('I am create.hac'); return;
[23:45] <rjb> at the top of create.hac; it does print
[23:45] <zumbrunn> so, now you know for sure where to debug :-)
[23:46] <jsp> another thing for the reference docs: req.data isn't an Object. none of the Object methods work on it.
[23:47] <zumbrunn> yes, there are many simplifications like this in the docs
[23:48] <rjb> no i don't
[23:48] <zumbrunn> there are objects floating around that are instances of Java classes
[23:49] <jsp> yeah. that sort of should be explicit so I won't beat my head against it for 20 min trying to figure out why the object methods don't work.
[23:49] <zumbrunn> and the docs currently lie about some of these things
[23:49] <rjb> http://helma.pastebin.com/d32dec4d9
[23:49] <rjb> that's the content of create.hac
[23:49] <zumbrunn> path for example isn't really an array either
[23:50] <zumbrunn> there the docs say it's a PathWrapper instance
[23:51] <jsp> bbl
[23:53] <zumbrunn> req.data should probably be documented as a Map instance
[23:55] <zumbrunn> rjb, where is the formHtml.skin defined?
[23:55] <zumbrunn> try this.renderSkin("formHtml");
[23:57] <rjb> Root/formHtml.skin
[23:58] <zumbrunn> renderSkin("formHtml"); tries to render a global skin by that name
[23:58] <zumbrunn> Root/formHtml.skin isn't global
[23:59] <rjb> i just followed the tutorial
[23:59] <rjb> (iirc)
[23:59] <rjb> but ok, that did it

 

 

In the channel now:

Logs by date: