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

2008-04-25:

[0:00] <zumbrunn> right
[0:00] <zumbrunn> that mountpoint behaves weird has come up a few times already
[0:00] <bslivka> but the mountpoint on that mountpoint's _id IS a number
[0:00] <zumbrunn> maybe mountpoint simply isn't intended to workm with the built-in db
[0:01] <bslivka> well that doesn't quite make sense to me either, given my (rather incomplete) understanding of helma
[0:01] <zumbrunn> mountpoint in my logic anyway should give you a collection of object of a certain prototype
[0:01] <zumbrunn> not just a single instance
[0:01] <bslivka> anything that's not mapped to a SQL db goes to the built in db right?
[0:02] <zumbrunn> yes, but I'm not sure which functionality really is supposed to work with the built-in db
[0:02] <zumbrunn> this might have been implemented purely for the relational mappings
[0:03] <zumbrunn> and the behavior maks discovered might be coincidental
[0:04] <bslivka> Right maybe that is the source of my confusion. It was maks that showed me what a mountpoint is, so really I'm operating on his understanding
[0:04] <bslivka> I couldn't find anything in the documentation that sensibly explains it
[0:05] <zumbrunn> yes, I know, not for how it behaves with the embedded db anyway
[0:05] <bslivka> The way I understand it, a mountpoint just maps a single object of the specified prototype on that property
[0:05] <bslivka> such that the url is directed to that object
[0:05] <bslivka> the url segment whose name matches the property name
[0:05] <zumbrunn> that's what "object" mappings are supposed to do
[0:06] <bslivka> Right.
[0:06] <zumbrunn> not the mountpoint mappings
[0:06] <bslivka> Mountpoint as you say should give a collection, whose prototype is a particular prototype?
[0:06] <bslivka> or a collection which contains a particular prototype?
[0:07] <zumbrunn> a collection of all objects of a particular prototype
[0:08] <zumbrunn> a collection of all instances of a particular prototype
[0:08] <bslivka> I thought that's what property = collection ( Prototype ) was supposed to do
[0:08] <zumbrunn> with "collection" it doesn't become accessible via the URL
[0:08] <bslivka> but it's been a while since I've worked with helma's mapped mode
[0:09] <zumbrunn> (it's not a mountpoint)
[0:09] <bslivka> ohhh
[0:09] <zumbrunn> collcetion mappings are only usable programatically
[0:09] <zumbrunn> where mountpoint ones become directly accessible
[0:09] <bslivka> that's funny cos for me they do generate urls
[0:09] <zumbrunn> that's the way I understand it
[0:10] <zumbrunn> but that's with the built-in db, right?
[0:10] <bslivka> well if I remember correctly, with mapped mode too
[0:10] <bslivka> Otherwise I would have needed mountpoints to build the most basic of applications
[0:11] <bslivka> And I didn't start using those until later
[0:11] <zumbrunn> hmm
[0:12] <bslivka> But it's tricky to know really because you can't directly map a "collection" to a database
[0:12] <bslivka> only its children
[0:12] <bslivka> well you can- You can map the hopobject prototype I guess
[0:13] <bslivka> but I don't know what that would accomplish
[0:13] <zumbrunn> I meant it's children anyway
[0:13] <zumbrunn> its children
[0:14] <bslivka> Well i'm confused
[0:15] <bslivka> I'm gonna go get some breakfast and mull it over. Be back in a short while.
[0:15] <zumbrunn> when you used collection mappings and they became accessible via the url, didn't you map the _children property in those cases?
[0:16] <zumbrunn> _children is special
[0:23] <bslivka> hrmn. sometimes
[0:24] <bslivka> not always
[0:28] <bslivka> though I'm confused by the question actually..
[0:28] <bslivka> _children is a property that you can map to a collection
[0:29] <bslivka> so if you map root's _children to a collection, the objects in that collection are directly accessable after the root
[0:29] <zumbrunn> right
[0:29] <bslivka> but if you map a regular property like "page" in root to a collection,
[0:29] <bslivka> the objects in that collection become accessable from /page/
[0:30] <zumbrunn> I thought only programatically via root.page.list()
[0:31] <bslivka> yeah, what I mean is, if you have an object with the id 56 in the page collection
[0:31] <bslivka> you can get it from /page/56
[0:31] <zumbrunn> I *thought* that you can't
[0:31] <zumbrunn> not with a collection
[0:31] <zumbrunn> only with a mountpoint
[0:32] <bslivka> *shrug* it's always just worked. Isn't that how it works in the addressbook example?
[0:32] <zumbrunn> checking...
[0:33] <zumbrunn> http://helma.org/docs/tutorial/collections/
[0:33] <zumbrunn> _children = collection(Person)
[0:37] <zumbrunn> anyway, what's the behavior you are looking for with the embedded db?
[0:38] <zumbrunn> you want /homepage/pages/foo/ ?
[0:38] <zumbrunn> which should point to a page object with the accessname "foo"?
[0:38] <bslivka> homepage/pages/4/ oughtta work
[0:39] <zumbrunn> ok, so just by id, no accessname
[0:39] <bslivka> well I haven't specified an accessname.
[0:39] <bslivka> What I expect to work is that the homepage mountpoint get properly persisted
[0:39] <zumbrunn> and what do you want to happen when accessing /homepage/pages/ and /homepage/ ?
[0:40] <zumbrunn> yes, I mean what's the functionality you want to achieve in the bigger picture
[0:40] <zumbrunn> (I'm not sure why you even need mountpoints)
[0:40] <bslivka> well, /homepage/ should retrive an object with prototype homepage
[0:41] <bslivka> and /homepage/pages/ should retrive an object with prototype page
[0:41] <bslivka> err pagemanager
[0:42] <zumbrunn> then why don't you do root.add(new HomePage())?
[0:43] <bslivka> First of all, it would be application functionality that isn't reflected in the overall structure of the source code
[0:43] <bslivka> but that's really a philisophical thing
[0:44] <bslivka> But the functionality obstacle is that in order for it to be persisted, I would need to specify _children on root as being of prototype Homepage
[0:44] <bslivka> a collection of prototype homepage rather
[0:44] <bslivka> and I don't want to limit myself to just the one prototype for that
[0:45] <bslivka> The built in DB I realize doesn't actually restrict that
[0:45] <bslivka> but Mapped mode does pay attention to which prototype you're adding
[0:45] <zumbrunn> yes, so it's because you later want to be able to switch the sql
[0:46] <bslivka> And third, where would I put that code such that it would only be executed once, ever?
[0:47] <bslivka> because if I run it a second time, it's erasing whatever changes I wanted persisted on the homepage object
[0:48] <bslivka> and if I run it in the shell, well, then it makes it difficult to really distribute the application.
[0:48] <zumbrunn> well, if it's just done once at initialisation, then you could do it in onStart and check if the object already exists or not
[0:48] <bslivka> Nevertheless yeah, basically it's exactly what I've done
[0:49] <bslivka> now I think about it..
[0:49] <bslivka> It's the workaround, but I feel that if you add a mountpoint, it should be persisted
[0:50] <bslivka> as it stands now it is only persisted if it is not attached to root, and and you access one of its properties
[0:50] <bslivka> or write to one of its properties rather
[0:50] <zumbrunn> yes, I'm not saying we shouldn't get to the bottom of how these things are supposed to work with the embedded db
[0:51] <zumbrunn> all this type.properties stuff is the gapping black hole in the documentation right now
[0:51] <bslivka> I think it's a gaping black hole in the logic of the framework, personally
[0:51] <bslivka> because you can't reflect the type.properties
[0:51] <bslivka> or modify them at runtime
[0:52] <bslivka> if you want to get a property from type.properties you need to parse the text
[0:53] <zumbrunn> as far as it pertains to the mountpoint/object mapping stuff, it might not be intended to work at all with the embedded db
[0:54] <zumbrunn> yes, configurability through code would be nice
[0:54] <bslivka> well I don't quite believe that proposition, because it looks to me like a common use of mountpoints may be with prototypes that aren't mapped to a DB
[0:54] <zumbrunn> a reform of all this is anyway intended to happen with the work on Helma NG
[0:55] <bslivka> in which case they get stored to the built in DB
[0:55] <bslivka> or not as the case may be..
[0:55] <bslivka> It may have gone unnoticed because most uses of mountpoint seem to be for little one off pages
[0:56] <bslivka> just off of root
[0:56] <bslivka> like "admin"
[0:56] <bslivka> or "about"
[0:57] <bslivka> getChildNode() is what is used for URL resolution right?
[0:57] <zumbrunn> are you looking at the java source?
[0:57] <bslivka> nope
[0:58] <zumbrunn> which getChildNode() ?
[0:58] <zumbrunn> checking...
[0:58] <bslivka> well getChildNode() is a function that the developer can write in a prototype
[0:58] <bslivka> Which I presume is overriding the default behavior of some built in getChildNode() function
[0:59] <zumbrunn> you mean getChildElement?
[0:59] <bslivka> that's the one
[0:59] <bslivka> my memory was hazy on the exact name
[0:59] <zumbrunn> that's only used if you define it
[1:00] <bslivka> Sure, but you could define function getChildElement (e) { return this.get(e) }
[1:00] <zumbrunn> but yes, if you define it, you can prettty much make helma do whatever you want
[1:00] <zumbrunn> right
[1:00] <bslivka> and it would behave exactly as default right?
[1:00] <zumbrunn> yes
[1:01] <bslivka> that's why the collection mapping /page/56/ works
[1:01] <bslivka> the one I talked about earlier
[1:01] <zumbrunn> using which mapping?
[1:02] <bslivka> on the root type.properties, you have page = collection ( Page )
[1:02] <bslivka> then you can access Page objects through a url like /page/56/
[1:02] <bslivka> which would get the page object with the _id = 56
[1:02] <zumbrunn> page = collection ( Page ) should give you this.page.get(56), not this.get(56)
[1:03] <bslivka> right
[1:03] <bslivka> but see this.page is a hopobject
[1:03] <bslivka> accessable from /page/
[1:04] <bslivka> so /page/56/ gives you this.page.get(56)
[1:04] <bslivka> or rather, this.get(56) is called in the context of the page HopObject
[1:04] <zumbrunn> right, *if* this.page is there
[1:05] <bslivka> which it is, because you've got page = collection ( Page )
[1:05] <bslivka> which generates a HopObject
[1:05] <zumbrunn> hmm, not sure
[1:06] <zumbrunn> maks recently reported something about this
[1:07] <bslivka> He was surprised when I told him too
[1:07] <bslivka> he had no idea this is what happened and thought it was because I was working with the built in DB
[1:07] <bslivka> but he had a mapped mode helma app handy and I made him out a shell command there
[1:08] <bslivka> he got the __prototype__ of a mapped collection
[1:08] <bslivka> and it says "HopObject"
[1:08] <zumbrunn> I never noticed that
[1:09] <bslivka> you can even add actions to the hopobject prototype
[1:09] <bslivka> and call them on collections
[1:09] <zumbrunn> ok, that proofs your point then
[1:10] <bslivka> that's what sparked him to put in a recent bug report about specific prototypes on collections
[1:10] <zumbrunn> right, that's the one I saw
[1:11] <bslivka> so that we can have specific actions in collections, not just the generic hopobject actions
[1:11] <bslivka> which forces you to add code to figure out which collection you're on to determine which code is valid
[1:11] <bslivka> unless you can make a collection with a specific prototype
[1:11] <bslivka> to which hannes replied
[1:12] <bslivka> Use mountpoints
[1:12] <zumbrunn> yes, but again, you could get the behavior you want by actually adding a HopObject to root and then using that as your collection
[1:12] <zumbrunn> that's what I'm doing and is the reason why I never bumped into this problem
[1:13] <zumbrunn> do you have the url of that bug handy?
[1:13] <bslivka> ermn not just now but I can find it
[1:13] <zumbrunn> I can look for it myself
[1:14] <zumbrunn> but I'll do so tomorrow
[1:14] <zumbrunn> time to catch some sleep
[1:14] <bslivka> okay. Thanks for the help
[1:15] <zumbrunn> btw, did you ever get the continuation stuff working the way you needed?
[1:15] <bslivka> I hate continuations. I don't know why I would want to try.
[1:16] <zumbrunn> who was then then?
[1:16] <bslivka> no idea
[1:16] <zumbrunn> I'll have to check the hopbot logs :-)
[1:17] <zumbrunn> ok, so... cu
[1:17] <bslivka> :) have a good rest

 

 

In the channel now:

Logs by date: