when is oid assigned to new content?

[Jo G]

Hi,

I have created a new content_type called Person (based on persistent). I want to make the name used for traversal unique and non editable by the admin users so for now I was going to use the OID assigned to my person object. Trouble is I can't see where the oid is set so I can't workout where to set name using set_oid.

I know it is set because a dump of the database shows me an OID. Where does this happen? 

Is it possible to set the name to be the OID?

I will also want to do the same with other content types (eg personalname) which are created when person is created.

I am new to python and dynamic languages so I may be barking up the wrong tree, if so please tell me!

Thanks

[Tres Seaver]

On 05/20/2015 11:07 AM, Jo G wrote:

> I have created a new content_type called Person (based on persistent). I
> want to make the name used for traversal unique and non editable by the
> admin users so for now I was going to use the OID assigned to my person
> object. Trouble is I can't see where the oid is set so I can't workout
> where to set name using set_oid.

The '__oid__' is normally set by the "object map" when the content object
is being added to it: at that point, the object must already be "seated"
in its folder, and therefore must have its initial '__name__' already assigned.

Generally, the OID is an implementation detail of the map, and probably
shouldn't be exposed to the user (even via the URL).

> I know it is set because a dump of the database shows me an OID. Where does
> this happen?
>
> Is it possible to set the name to be the OID?
>
> I will also want to do the same with other content types (eg personalname)
> which are created when person is created.
>
> I am new to python and dynamic languages so I may be barking up the wrong
> tree, if so please tell me!

For your usecase, I would likely use a different container than the
standard 'substanced.folder.Folder'. E.g., the
'substanced.folder.AutoNamingFolder' type generates random IDs for its
sub-objects. If you then want to prohibit renames, you would need to
derive from it and override the 'rename' or 'move' methods (inherited from
'substanced.folder.Folder').

Rather than overriding those methods, another option would be to add a
subscriber for the 'substanced.events.IObjectWillBeRemoved' event and block
removal if its 'moving' flag is True. E.g.:

from substanced.events import subscribe_will_be_removed

@subscribe_will_be_removed(Person)
def person_will_be_removed(event):
if event.moving:
raise ValueError('cannot move/rename Person')



Tres.
--
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com

[Jo G]

Tres, many thanks for this, I was beginning to think the oid wasn't the way to go. I will look at inheriting from the AutoNamingFolder.

[Jo G]

Ok, and the next question. 

Each Person object can have zero to many names and each of those names can have one to many parts. I am therefore using a personal_name object and a personal_name_component object. At the moment I have a property of the Person object which contains personal_names and the personal_names object has a property which contains the personal_name_components. I then 'add' everything to do with the person on one form with nested schema.  To get the sub objects to be retained when I then try and edit my person I have to assign them a __name__ property (presumably so they can be included in the object map). If I do a dump of the database at this point the sub objects appear in the propertysheets rather than as separate resources. I assume though that they must have an OID I just can't see it?

Again, I don't want the user to decide on the names for the personal_names or personal_name_components so does that mean making an autonamingfolder of personal names to store the names in and an autonaming folder of personal_name_components? The names and name components would never be associated with anything other than the one person or be edited independently of the person.

Thanks

On Wednesday, 20 May 2015 19:35:08 UTC+1, Tres Seaver wrote:

[Tres Seaver]

On 05/21/2015 05:26 AM, Jo G wrote:
> Again, I don't want the user to decide on the names for the personal_names
> or personal_name_components so does that mean making an autonamingfolder of
> personal names to store the names in and an autonaming folder of
> personal_name_components? The names and name components would never be
> associated with anything other than the one person or be edited
> independently of the person.

I'm not sure I would be making the 'personal_name' and
'personal_name_components' bits into separately-managed content objects.
Instead, I think I would be using the rich schema support in colander to
make them into fields within the 'Person' schema.

[Jo G]

Yes, unfortunately there are other reasons that they need to be separate objects but to all intents and purposes they are just properties of a person.