Hopbot log for 2008-08-05 - Helma IRC channel: #helma on irc.freenode.net
2008-08-05:
[10:05] <daniel_> zumbrunn, the helme reference is incomplete. HopObject is missing the properties _prototype and _name[10:12] <zumbrunn> daniel_, yes, that has come up before... I keep wanting to add them
[10:13] <zumbrunn> there are more of these magic properties, not just those two
[10:13] <zumbrunn> another two are for the creation and modification date/time, I believe
[10:14] <zumbrunn> and I think it depends on whether you use the embedded db or a mapped prototype
[10:18] <daniel_> a complete list is in HopObject.java:getInternalProperty()
[10:18] <zumbrunn> thanks
[10:19] <daniel_> as far i can see there, the rhino engine does not distinguis between persistent and transient nodes
[10:19] <daniel_> but it might well be, that the methods called there don't deliver anything in either situation
[10:20] <daniel_> and you were right, there are a lot more than i remembered (-;
[10:20] <zumbrunn> yes, for transient ones it might differ as well
[10:21] <zumbrunn> I guess I just document what *could* be there
[10:23] <daniel_> i just had a deeper look into it, all methods called there to retreive the values are defined in the INode interface.
[10:23] <daniel_> so they really should be there, wherever nodes come from or if they are transient or not.
[10:24] <daniel_> i'd comment all of them, because if it really happens, that a value does not exist, i'd call it an implementation bug
[10:25] <daniel_> and if so, don't let us have both, implementation and documentation bug (-:
[10:27] <zumbrunn> any ideas when __fullname__, __hash__ and __node__ are useful?
[10:28] <daniel_> node is the internal node for the hopobject
[10:28] <daniel_> hopobject is what is exposed to js, node is what is used internally and i'd say should never be exposed to the scripting language, but well ...
[10:29] <zumbrunn> almost a year to the day since I first wanted to document this:
[10:29] <zumbrunn> http://helma.zumbrunn.com/hopbot/2007-08-08
[10:29] <daniel_> lets find out what fullname and hash are good for exactly
[10:31] <daniel_> fullname is somewaht similar to href() from what i can see
[10:31] <daniel_> it gives you a full name like Root/myname/myname/...
[10:41] <daniel_> __hash__ is the only poperty only available on persistent nodes
[10:42] <daniel_> it is the hash value of the internal node and the interal prototype, thus it is probably intended for js hashing of objects
[10:51] <daniel_> __created__ and __lastmodified__ may be written in any case, all the others are case sensitive
[10:51] <daniel_> only _id, _parent and _prototype may be written in either syntax (_lala or __lala__)
[10:51] <zumbrunn> that's weird
[10:52] <daniel_> yep.
[10:52] <daniel_> agreed (-:
[10:52] <zumbrunn> (the non-case-sensitive bit)
[10:52] <daniel_> i do like backwards compatibility, but changing something like this your js source code is kind of simple search replace...
[10:53] <daniel_> once something is deprecated it should be dropped at least some time in the future (-:
[10:53] <zumbrunn> oh, it will be ;-)
[10:53] <daniel_> was this helma ng joke?
[10:56] <daniel_> HopObject.subnodeRelation is missing in the reference too
[10:56] <zumbrunn> it crossed my mind that you could read it like that while I typed it, but no, it wasn't actually intended as a ng joke
[10:57] <zumbrunn> hmm, never came across HopObject.subnodeRelation
[10:59] <daniel_> it allows you to manually adjust the .filter from type.properties
[11:00] <zumbrunn> wow!
[11:00] <zumbrunn> a few years ago I looked through the HopObject source for undocumented properties/methods
[11:00] <daniel_> i can remember it was introduced in the days where getOrderedView did not exist yet
[11:00] <zumbrunn> but that one is pretty well hidden in the source
[11:00] <daniel_> back then, once set, it overwrote any filter settings set in type.properties
[11:01] <daniel_> i say back then, because a lot changed in the type.properties since back then, so although subnodeRelation is still in the source, i am not sure if it still works as intended if you have complex filters in your type.properties
[11:03] <zumbrunn> http://dev.helma.org/wiki/Helma+Reference+Errata/
[11:04] <daniel_> yep thats it. thanks.
[11:05] <daniel_> i didn't know this page, will make comments there myself if i find more..
[11:11] <daniel_> i wonder if it is possible to add a child to a collection twice or more?
[11:17] <daniel_> tried it and no it is not possible.
[11:18] <daniel_> sounds like a stupid question, but it came up when i read what the docs say to HopObject.add (Boolean true if the addition was successful.) and what the source actually does.
[11:19] <daniel_> the source tries to add the child and returns true. it does not check if the child has already been added before and was thus not added successufully.
[11:20] <daniel_> helma bug, doc bug or just me taking it too serious? (-:
[11:21] <daniel_> anyway i will continue to report any findings.
[11:21] <zumbrunn> either-way something that probably can't be changed at this point?
[11:23] <daniel_> well, if one __would want__ to have that detail at least somewhere, the docs could say "..if the addition was successful or the child was present before"
[11:23] <zumbrunn> yep
[11:23] * zumbrunn is doing that
[11:25] <daniel_> i am not even sure if there is a helma application out there that distinguishes between "added now" and "not added now, was already added", but i think at least the docs should have the detail
[11:28] <daniel_> same for addAt()
[11:31] <daniel_> for addAt() as for add() true is returned all the time. the difference however is that true is ok for addAt() as the child is either added (if it was not already present) or moved to the new index (if it already was present).
[11:33] <daniel_> without that behaviour some might think removeChild() followed by addAt() is needed to move a child
[11:33] <zumbrunn> "If the subnode is already attached, it will be moved to the specified index position."
[11:34] <daniel_> did i miss that? lets have a look
[11:35] <zumbrunn> with add() the subnode doesn't move to the last index position?
[11:35] <zumbrunn> no, no...
[11:35] <zumbrunn> that's what I'm adding
[11:35] <daniel_> ah ok, yes
[11:35] <zumbrunn> "Boolean true if the addition or move was successful."
[11:36] <daniel_> ok
[11:36] * daniel_ looking again at add()
[11:38] <daniel_> i am sorry, yes it is moved
[11:38] <zumbrunn> good
[11:38] <daniel_> so both add() as well as addAt() do a move if the subnode is already present
[11:39] <daniel_> which is even more important to know for add() (-:
[11:40] <zumbrunn> "If the subnode is already attached, it is moved to the last index position."
[11:41] <daniel_> correct
[11:42] <daniel_> btw, any out of range index moves it to the last index position
[12:10] <zumbrunn> aren't the deprecation warnings for HopObject.remove(child) just an exception?
[12:11] <zumbrunn> I think this was just well intended paranoia because it was a pretty dangerous/major change
[12:12] * zumbrunn has nothing against adding more deprecation warnings, though
[12:15] <daniel_> true, but there shouldn't be only one exception
[12:15] <daniel_> otherwise the user want note that other methods are deprecated too, until he switches to a new helma version and suddenly everything stops working
[12:19] <daniel_> so i consider not informing the user, neither in java source nor with log output a bug
[12:20] <daniel_> the HopObject.remove(child) warnings are currently logged to System.out, which most users won't see anyway, if helma is started as background daemon )-:
[12:20] <daniel_> need to add that to the bug...
[12:21] <zumbrunn> yeah, the event log of the app would be better
[12:24] <daniel_> why was HopObject.contains() marked deprecated?
[12:24] <daniel_> because of the misleading return value?
[12:25] * daniel_ would love to have it with boolean return value a.contains(b) instead of a.indexOf(b) >= 0
[12:25] <zumbrunn> and because indexOf is standard Javascript for this behavior
[12:26] <daniel_> is this true for list() to?
[12:26] <daniel_> in java i would name it getChildren() or toArray()
[12:26] <zumbrunn> list() is another whole in the docs
[12:27] <zumbrunn> we should probably document "collections" separately from HopObject somewhere
[12:27] <daniel_> what do you mean? list() is explained quite in detail in the docs
[12:27] <zumbrunn> checking...
[12:28] <daniel_> even so much in detail that the conclusion is that list() shoul not be used because it tends to have poor performance under certain circumstances
[12:29] <zumbrunn> hehe
[12:29] <zumbrunn> yes, but the collection you get back from list has some but not all of the HopObject methods
[12:30] <zumbrunn> or have I got that wrong?
[12:30] <daniel_> isn't it an array?
[12:30] <daniel_> docs say its an array
[12:30] <zumbrunn> no, it's something special...
[12:30] <daniel_> lets check the source...
[12:30] * daniel_ checking
[12:31] <zumbrunn> or maybe I'm confusing something and remember wrong
[12:31] <daniel_> its for sure an array
[12:31] <zumbrunn> hmm, ok
[12:31] <daniel_> i think you might think of orderedViews ?
[12:31] <zumbrunn> could be
[12:31] <daniel_> lets see what exactly they return
[12:32] * daniel_ sees and learns from it
[12:32] <zumbrunn> I remembered a ListWrapper or something like that
[12:32] <daniel_> yes ListViewWrapper
[12:32] <daniel_> whatever that might be...
[12:33] <daniel_> i see...
[12:33] <daniel_> its kind of a HopObject
[12:33] <daniel_> as you said... some equal functions but not all
[12:36] <daniel_> ListViewWrapper is quite weird
[12:37] <daniel_> it has some but not all functions of HopObject, out of the ones it has, some are forwarded to HopObject and only a few are not; some exist but but throw exceptions
[12:38] <daniel_> all functions that would exist on a HopObject and modify it throw exceptions
[12:39] * daniel_ now knows that ListViewWrapper is a read-only collection of HopObjects
[12:40] * daniel_ however does not know why not working functions are implemented at all, thus making the collection look more like a HopObject which it not is
[12:45] <daniel_> i would prefer if there would be a HopCollection (for what is actually working in ListViewWrapper) and have HopObject extend it
[12:46] <daniel_> that would be much more consistent
[13:30] <daniel_> HopObject.invalidate() has a return value of boolean, true is returned all the time however
[13:32] <daniel_> i would consider this a helma bug as HopObject.invalidate(wrongChildId) should not return true as TransientNode.invalidate() should not return true
[13:32] <zumbrunn> what's the proper way of documenting that?
[13:32] <zumbrunn> oh
[13:33] <daniel_> i will file a bug report. right now you can only document "always true" which does not help at all
[13:33] <zumbrunn> yes, documenting that feels a bit weird
[13:34] <zumbrunn> "returns Boolean always true" ;-)
[13:34] <daniel_> i would even correct it, but i do not have svn write access /-:
[13:34] <zumbrunn> did you have cvs write access?
[13:35] <zumbrunn> maybe we should move helma 1.x to git as well
[13:35] <zumbrunn> my git experience so far has been really positive
[13:35] <daniel_> no i never had
[13:36] <zumbrunn> just ask hannes for svn access, if you like
[13:36] <zumbrunn> are you using git?
[13:36] <daniel_> i do not know git yet, whats the advantage having sources over there?
[13:36] <zumbrunn> it's really a very different way of working
[13:37] <zumbrunn> there isn't really a central repository
[13:37] <zumbrunn> you have a local copy of the entire repository
[13:37] <zumbrunn> and you can pull and push things from and to other repositories
[13:38] <daniel_> need to have a closer look at git
[13:38] <daniel_> what i would love to have is a language aware repository
[13:39] <zumbrunn> language aware?
[13:39] <daniel_> that could still diff things, if only the formatting changed
[13:39] <daniel_> because helma 1.x would really need reformatting
[13:41] <zumbrunn> well, linus torvalds claims git doesn't track files, it tracks code
[13:41] <zumbrunn> so maybe you are in luck
[13:41] <zumbrunn> (for example individual functions across different files, even)
[13:42] <daniel_> the problem with svn right now is that if you would reformat helma 1.x, you culdn't diff it anymore to any older revisions
[13:42] <zumbrunn> but those are power features I didn't get to yet
[13:57] <daniel_> had a quick look at git as well as at other systems but couldn't find any that are language aware
[13:58] <zumbrunn> what do you mean by "reformat"?
[13:58] <zumbrunn> more than just whitespace?
[14:00] <daniel_> yes, a lot more
[14:01] <daniel_> [Helma code tries to adhere to Sun's Java Code Conventions.]
[14:01] <zumbrunn> ok, then I see what you mean
[14:01] <daniel_> but, follow the link
[14:02] <daniel_> this sun java code conventions are as of 1999
[14:02] <daniel_> or was it 1998, however...
[14:02] <daniel_> i'd say the eclipse built-in code convetions with some minor adjustments are what it should be
[14:03] <daniel_> i am using them now for some years and it really improves readability, development performance and helps to prevent lots of mistakes
[14:06] <daniel_> but beside code conventions, code style guidelines are even more important
[14:07] <daniel_> concerning both, helma 1.x code a lot of times is damn ugly
[14:23] <daniel_> is there a special reason why there is HopObject.invalidate(id)?
[14:24] <daniel_> there is no need for it as i always can do HopObject.get(id).invalidate()
[14:25] * zumbrunn doesn't disagree
[14:26] <daniel_> if you would have disagreed i would have said that all other functions should have an additional id argument too ((-:
[14:26] <daniel_> list(id) get(id, id) (deep getting *g*), ...
[14:26] <zumbrunn> yeah, but I didn't :-)
[14:27] <daniel_> but what to do with that finding.. its not a bug.. looks like i will sum it up in a "make helma more consistent" rfc
[14:46] * daniel_ has summed up the things found so far http://dev.helma.org/wiki/HOWTO+improve+Helma+1.x/
[15:30] <mmonster> connected with mibbit.com
[15:30] <mmonster> seems like it might be a pretty nice online irc client
[15:31] <mmonster> zumbrunn, take a look at http://www.mibbit.com/widget.html ? I think this could work a lot better than the java IRC widget we have
[15:33] <zumbrunn> yes, I thought that could be the case a few days ago, when I saw someone else using it here
[15:33] <zumbrunn> but I didn't take the time to look at it yet
[15:36] * daniel_ thinks he has 60% of the code, needed to use php as alternative scripting language, done
[15:38] <daniel_> implementing the helma php plugin seems to be easier than it might have been to implement the rhino plugin.
[15:38] <zumbrunn> lol
[15:38] <Helma1> lol
[15:38] <mib_higddi> lol
[15:39] <daniel_> additionally a lot of code is shared right now, once done with the php plugin, i will move it to abstract classes which should allow other scripting engines to be written even easier and faster
[15:39] <daniel_> -shared +duplicated
[15:39] <daniel_> if it already would be shared, things would be fine (-;
[15:41] <daniel_> so, mmonster, lisp and / or scheme support is getting closer (-;
[15:42] <zumbrunn> yeah, I know more people that will be excited about scheme support than php support!
[15:42] <zumbrunn> of course, I know that's not representative of the real world
[15:43] <daniel_> the next bigger step will be to allow helma 1.x to run several scripting engines at once to make it possible to cross code
[15:44] <zumbrunn> daniel_, you've been using the pjirc irc java applet at http://helma.zumbrunn.com/irc/ - right?
[15:59] <midnightmonster> I keep running into pain with the ORM. It's bumming me out.
[15:59] <daniel> mm, what would you like to do / to know?
[15:59] <daniel> z, HopObject.update() has an int return value (number of nodes updated)
[16:01] <zumbrunn_> what I was saying, when I was so rudely interrupted by the netsplit:
[16:01] * daniel added it to http://dev.helma.org/wiki/Helma+Reference+Errata/
[16:01] <zumbrunn_> what do you think about switching to mibbit?
[16:02] <zumbrunn_> and...
[16:02] <zumbrunn_> yes, being able to write modules in different language would be what is really interesting, I think
[16:02] <midnightmonster> I'd like to quit feeling like I'm working magic. *oops--that didn't work all the way. forgot to include one word in the incantation.*
[16:03] <daniel> need to have a look at mibbit
[16:04] <midnightmonster> latest was I'd create a new object of a type that has several collection members. trying to access one of the collections resulted in null instead of an empty collection until I restarted the app.
[16:04] <midnightmonster> (it was repeatable)
[16:04] <midnightmonster> so I found that if I invalidate the object after I res.commit, it works out ok
[16:05] <daniel> who can a newly created object have subnodes?
[16:06] <midnightmonster> they're collections defined as a select from the DB. they should be empty, no doubt, but they should be empty collections, not null
[16:06] <daniel> the issue you describe might be that a transient node can not have subnodes or at least helma does not try to load the subnodes as long as the newly created node is still transient
[16:06] <midnightmonster> it doesn't try to load them once it's saved, either
[16:06] <midnightmonster> until you invalidate it
[16:07] <daniel> res.commit should be enough
[16:07] <midnightmonster> it's not
[16:07] <midnightmonster> ?actually, I suspect that it does load them for collections created more traditionally, i.e., with the foreignkey sub-properties
[16:07] <midnightmonster> the collection in question was done with a filter
[16:07] <daniel> traditional + filter or just filter?
[16:07] <midnightmonster> just filter
[16:08] <daniel> might be a bug then
[16:08] <daniel> i will have a look what exact magic the invalidate does so that it works for you after calling it
[16:08] <midnightmonster> it expires the object out of the object cache
[16:09] <midnightmonster> so next time it's looked up fresh.
[16:09] <midnightmonster> so all the collections are re-looked up too
[16:12] <midnightmonster> I'm pretty sure this is a bug, and it's probably fixable, but I'll have to dig in and make a test case, and possibly propose a fix, and test the fix, and... this is a lot of time to spend
[16:14] <daniel> if it fixes a bug its probably worth the time spent (-;
[16:17] <__daniel__> z, as an irc applet i prefer the current one over mibbit
[16:18] <midnightmonster> my big opposition to the current one is that you have to grant it massive privileges. I wasn't willing to do that, so haven't used it.
[16:18] <__daniel__> the current one is somehow simpler and cleaner
[16:19] <midnightmonster> __daniel__, perhaps mibbit in widget form is a bit simpler?
[16:19] <zumbrunn_> http://www.mibbit.com/widget.html
[16:21] <mmonster> I set it with the helma server and channel, no server tab, and prompt for nickname.
[16:21] <mmonster> with a color change, I love it
[16:23] <daniel> with these settings, i guess i could like it to
[16:23] <daniel> i will however miss the fullscreen window mode
[16:24] <daniel> i should have called it native window mode... as it is a window, it can't be fullscreen (-;
[16:25] <mmonster> there's no reason I can think of that a mibbit widget couldn't be opened in a maximized, de-chromed browser window.
[16:26] <zumbrunn_> http://embed.mibbit.com/?server=irc.freenode.net&channel=%23helma
[16:28] <daniel> i should use a desktop app anyways, i am just too lazy to start one.
[16:43] <__daniel__> pidgin (gnome) is fine too
[16:45] <zumbrunn_> yeah, well, can't put that into that webpage
[16:52] <daniel> for the intended purpose, the mibbit "applet" seems to be the better choice, as it does not require a jvm
[17:20] <zumbrunn_> true, haven't even thought about that
[17:21] <zumbrunn_> then again, folks without a jvm are probably not the core audience for helma
[17:22] <zumbrunn_> but for exmaple mibbit works on the iphone
[17:23] <zumbrunn_> which is a good thing since there is currently no native irc client anymore due to the 2.0 firmware upgrade
[17:27] <daniel> agreed, that folks without a jvm are probably not the core audience, but even the core audience might want to access the irc applet from somewhere else than their own workstation
[17:28] <daniel> don't have an iphone so far, but if mibbit works for iphones, it might well work for other smartphones too i guess
[17:29] <daniel> at least other smartphones / mobile phones allow to install a java irc client if nothing else works
[17:39] <midnightmonster> (Detail: what I actually did before was invalidate the problematic collection on the newly created object, not the newly created object itself)
[17:40] <daniel> might have been the problem, as the collection is always transient and thus can not be invalidated
[17:40] <midnightmonster> nope--I mean that's what I am actually doing to fix it
[17:41] <midnightmonster> I misremembered
[17:41] <daniel> oh
[17:41] <midnightmonster> I expect that invalidating the whole new object would also work, and I'm going to test in a bit after I sort out another bug
[17:42] <midnightmonster> oops, I was right the first time.
[17:43] <midnightmonster> I am invalidating the new object right after I commit it.
[17:43] <daniel> that again makes sense, the new node is persisted after commit and can thus be invalidated
[17:44] <daniel> the new node however should already be persisted right after you add it to some other node that already is persisted itself
[17:45] <midnightmonster> you don't normally have to add nodes to other nodes with the ORM
[17:45] <midnightmonster> in the sense of using .add()
[17:45] <midnightmonster> just calling this.persist() does it
[17:46] <midnightmonster> and the parent collection updates automagically
[17:46] <midnightmonster> it might work just fine to call invalidate() before the res.commit().
[17:46] <midnightmonster> but I haven't tried yet
[17:47] <midnightmonster> invalidating collections also works, though, b/c I do it ?elsewhere when something happens that changes the output of the filter
[17:47] <daniel> agreed, persist does the same as adding
[17:48] <midnightmonster> I think what this amounts to is that collections with filters don't know when something relevant has changed, and all the magic that applies to non-filtered collections doesn't work for them
[17:58] <midnightmonster> hmm. I have 4 collections defined in type.properties for this type. two use filters, two use foreign keys. when I make a new one, all 4 are null.
[17:59] <midnightmonster> (new one=new object of this type)
[18:00] <daniel> you mean like var a = new MyType(); res.writeln(a.myCollection);
[18:01] <midnightmonster> right, except I'm talking about post-commit during the next request
[18:01] <midnightmonster> ohwaitIthinkImightbestupid
[18:04] <zumbrunn_> owitimbs... a new acronym is born
[18:05] <midnightmonster> (at least I can salvage "coiner of acronyms" out of my shame here)
[18:07] <midnightmonster> confirmed: I am indeed stupid
[18:07] <daniel> lol
[18:10] <midnightmonster> I wrote a neat little function that updates hopobjects based on data posted from a form. it does smart things like handle booleans and common date fields and object() fields based on some assumptions that are true for my apps at least. it also knows to ignore properties with names matching certain patterns without having to be told. but I forgot to exclude collections and mountpoints.
[18:10] <midnightmonster> so they were getting treated with the default (for plain text) this[name] = post[name];
[18:11] <midnightmonster> and post[name], of course, was undefined
[18:12] <midnightmonster> you can't permanently knock out a collection that way--they come back when object is re-retrieved from the DB (as after invalidate)
[18:12] <midnightmonster> I actually feel tremendously better knowing I'm stupid than I did when I was thinking helma was doing weird-ass stuff
[18:15] <daniel> we however still need to answer the question, if this is flexibility (we can overwrite all and everything if we like) or a bug
[18:16] <daniel> <sarcasm>helma ng spupporters would probably say this is flexibility</sarcasm>
[18:17] <zumbrunn_> yep
[18:17] <daniel> i would prefer to have an app property like strict=true/false and consider it a bug if strict is set to true
[18:19] <zumbrunn_> clearly, being able to easily notice and debug stuff like this is an honorable goal
[18:19] <daniel> actually i would call it a bug and simply not allow it to overwrite a collection, but one always needs to think about solution that might reach as deep as into the svn (-;
[18:20] <midnightmonster> setting any of the collections should have triggered a TypeError or something like that
[18:20] <midnightmonster> I can't think of any good reason to do that
[18:21] * daniel either
[18:21] <daniel> so you might want to file a bug report please
[18:21] <midnightmonster> there's already a way to set properties as imutable in helma
[18:22] <daniel> you mean the readonly flag?
[18:22] <midnightmonster> yeah
[18:22] <midnightmonster> I'm going to see what happens if you set that on a collection
[18:22] <daniel> it should be the other way around however for overwriting collections
[18:22] <midnightmonster> agreed.
[18:22] * zumbrunn_ agreed
[18:23] <midnightmonster> but if setting it gets the desired behavior (collection still works like normal, but you can't overwrite it), then this should be a very small fix in the source
[18:24] <midnightmonster> well, except object(Whatever) fields are supposed to be setable, but only with an appropriate object
[18:24] <midnightmonster> I wonder what happens if you try to set one to something else
[18:28] <daniel> does the readonly flag work?
[18:28] <midnightmonster> haven't tried yet
[18:28] <midnightmonster> busy playing with setting object()'s to strings
[18:29] <midnightmonster> setting works. but retrieving later blows up in ajavland
[18:29] <midnightmonster> javaland
[18:30] <midnightmonster> but setting to an object of the wrong type fails on setting
[18:30] <midnightmonster> as desired
[18:30] * daniel might be he stupid one now
[18:31] <daniel> i was able to find the location in the source code where the readonly flag is parsed but i couldn't find any place where it is actually taken into account
[18:31] <midnightmonster> *it's a stupid club!!*
[18:31] <midnightmonster> 'bout to try it
[18:31] <midnightmonster> I have a couple normal fields that really should be readonly. and I'll try on the collections as well
[18:32] <daniel> ah! the only one that uses the readonly flag is the NodeManager
[18:33] <daniel> so a property is only readonly in the sense that it will not be written back to the database if it was changed
[18:34] <midnightmonster> confirmed.
[18:34] <midnightmonster> that sucks
[18:34] <daniel> the scripting engine however does not take it into account, so you can set it to whatever you like /-:
[18:35] <daniel> agreed (-:
[18:36] <daniel> setting an object reference to something not an object is a bug for sure
[18:36] <daniel> well, i mean, if it blows up javaland... (-;
[18:37] <daniel> what is the error message if you set it to an object with wrong type?
[18:37] <daniel> (helps me to find the source code location a bit faster)
[18:38] <daniel> ah ok found it
[18:38] <midnightmonster> Can't set mfgupc to object with prototype Mfg, was expecting UPC
[18:38] <daniel> blame the scripting engine again
[18:39] <daniel> the scripting engine uses different methods for setting nodes and setting other things... so if you set it to something not a node, no checks will be applied /-:
[18:39] <midnightmonster> not so good.
[18:40] <midnightmonster> is bugzilla still the official bug location?
[18:40] <daniel> i hope
[18:40] <daniel> otherwise noone would read my bug reports
[18:40] <midnightmonster> zumbrunn, is bugzilla still the official bug location?
[18:41] <daniel> i will post a comment on how to fix it once you filed the bug report
[18:42] <zumbrunn> midnightmonster, yes it is
[18:45] <midnightmonster> http://helma.org/bugs/show_bug.cgi?id=632
[18:58] <daniel> i've added my comment
[19:16] <midnightmonster> thanks for the help digging into it. hopefully the fix suggestions will help it get fixed sooner