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

2007-09-07:

[22:46] <rjb> can hopobject collections have actions attached to them? that's something i can't figure out
[23:25] <zumbrunn> rjb, "collections" can't
[23:25] <zumbrunn> actions are "attached" to prototypes
[23:25] <zumbrunn> but since objects in a collection are of some prototype, you should be able to get the behavior you want
[23:28] <rjb> you mean, a collection has no prototype where i could define an action, right?
[23:28] <rjb> ok let me ask another question
[23:28] <zumbrunn> not that I know of, correct
[23:29] <rjb> in apps/welcome/code/HopObject/type.properties
[23:30] <rjb> the last line is not an assignment, but reads simply 'name' instead
[23:30] <rjb> what does that do?
[23:31] <rjb> {ok what i really meant to ask before,
[23:32] <zumbrunn> all the type.properties behaviors need to be documented much better
[23:32] <rjb> it's very natural to have url paths like parentObjectName/collectionName/accessName
[23:33] <rjb> and that works fine for me
[23:33] <rjb> but i also want parentObjectName/collectionName/specialAction
[23:33] <zumbrunn> I'm not sure myself, but without the name property being defined the way hopobject collections are mounted to URLs behaves not as expected
[23:34] <zumbrunn> ie it iterates between mounting based on the name property and the id
[23:35] <zumbrunn> what would the special action do?
[23:35] <rjb> some management of the collection as a whole
[23:36] <zumbrunn> hopobjects are themselves collections, so you could define them as hopobject prototypes instead of just collections
[23:36] <rjb> how would that read in type.properties?
[23:37] <zumbrunn> it wouldn't depend on type.properties
[23:37] <rjb> ok, i'm thoroughly confued
[23:37] <rjb> confused even
[23:37] <zumbrunn> instead you would attach hopobjects to a parent hopobject of a certain prototype that serves as your collection
[23:39] <rjb> assuming i use the built-in persistence, i understand i only need to do that once
[23:43] <zumbrunn> in a sense, "collections" that you define in type.properties allow you to prevent the need to create "dummy hopobject prototypes" if all you want is the "collection behavior"
[23:44] <rjb> ok i could always trick the app into doing what i want by writing a suitable getChildElement()
[23:44] <zumbrunn> but since in your case you want more, I think it makes sense to actually define a hopobject prototype and attach such an instance to the hopobjects where you would have defined such a collection
[23:50] <rjb> right. thx for pointing out that any hopobject can be used to implement a collection
[23:50] <rjb> i was missing that point
[23:55] <rjb> ok, what i now have is a root with _children.accessname=id
[23:57] <rjb> those _children are mapped to a mysql table
[23:58] <rjb> now i'd like to add a singleton object root.ol of a different prototype, and persist it in helma's xml store
[23:59] <rjb> as a holder for some management actions
[23:59] <rjb> so, i've got an OL prototype
[23:59] <rjb> in Root/type.properties: ol = object(OL)

 

 

In the channel now:

Logs by date: