With the fix for bug 79, Helma complains (rightly) when adding skin objects to root, since skin objects have an object reference to weblog. After changing that reference to a simple integer property, things work! But not really! Because now root skins have a value of 0 in their WEBLOG_ID field, which happens to be the ID of the root object, but would be mistaken for a weblog id.

So... I think the solution is to extend object references to be able to handle references to different tables/types. I messed around a bit and this is what I came up with. For simple object references (in our case, skin objects' reference to the containing object - notice that I replaced "weblog" with "owner"):

owner = object () owner.local = OWNER_ID owner.foreign = ID owner.table = OWNER_TABLE

And for collections (in our case skinmgr)

_children = collection (skin) _children.local = ID _children.foreign = OWNER_ID _children.table = OWNER_TABLE

I discussed something like this a few days ago with Tom Förster. Comments?

just curious: how could one make root "look like weblog"?

I was talking about duplicating the functions of weblog in root.

i found out what i submitted as bug 79 ;-) i did exactly what you described above, and i came to pretty the same conclusion, except that i wouldn't specify the table, but the name of the prototype-column:

owner = object () owner.local = OWNER_ID owner.foreign = ID owner.table = OWNER_PROTOTYPE

or _children = collection (skin) _children.local = ID _children.foreign = OWNER_ID _children.prototype = PROTOTYPE

this seems pretty consistent to me (.prototype is already used in type.properties-format 1.2).

between "table" and "prototype". But the notation isn't very clear yet. In the first case, with an object reference,

owner.prototype = OWNER_PROTOTYPE

it's quite clear that we're talking about a local column describing the prototype of the referenced object. But in the case of the collection,

_children.prototype = OWNER_PROTOTYPE

it looks just the same, while it's the other way round. I tried mixing in some pieces of "local" and "foreign", but it remains just as confusing (to me, at least).

"table" appears wrong to me, because it actually defines a column. but you're right: in case of collections this is really confusing (while in case of object-references it looks pretty logical for me) ...

_children.parentprototype = OWNER_PROTOTYPE

I think the "parent" fits well with the "_children". The original version

_children.prototype = CHILD_PROTOTYPE

could mean a local column defining the prototype of child objects, although I'm not sure we'll need this.

definetly a better way to describe that, but it's still not absolut logical. i assume you already checked this:

_children.foreignprototype = OWNER_PROTOTYPE

to some point this makes sense to me, because _children.foreign = OWNER_ID also references a foreign column defining the parent's id. so the whole stuff would look like this:

_children=collection(skin) _children.local=ID _children.foreign=OWNER_ID _children.foreignprototype=OWNER_PROTOTYPE

but this also might be confusing, because .foreignprototype could easily be misunderstood for defining the children's prototype ... so i think your suggestion is definetly best.

(but maybe we should discuss this on hop-mailinglist)

I just removed a collection (aka virtual subnode) from weblog objects. Even if we had removed any files, CVS would do that for you as part of updating.