[CPS-devel] computeId customisation

[Winterflood, Jonathan]

Ok, so it's a bit ugly, but it's safe.

For now I'll leave it as it is I think, since I've got more urgent things to tend to...
If I get some time I'll look into CPSUid.

Thanks a lot for your time

Jonathan

-------- Message d'origine--------
De: Georges Racinet [mailto:gracinet at nuxeo.com]
Date: jeu. 15/02/2007 11:47
À: Winterflood, Jonathan
Cc: cps-devel at lists.nuxeo.com
Objet : Re: RE : [CPS-devel] computeId customisation
 

On Feb 15, 2007, at 10:26 AM, Winterflood, Jonathan wrote:

> Thanks a lot
>
> >It is indeed some kind of a hack: generateId is suppose to provide
> >disambiguation within the given container.
> >If you're really new to Zope, I should maybe point out that this
> >notion of id is by no means global.
>
> I understand this script is used by CPS to create id's for the  
> proxies to documents
Right, but only for user-triggered creation of a fresh document and  
first proxy to it.  The "invokeFactory" script expects a valid Id and  
is the one to be used
in programmatic situations. It's actually just a wrapper to the  
workflow tool's invokeFactoryFor method

> these proxies circulate different workspaces in CPS (passed from  
> private per-user spaces to common spaces, mostly)
They can be moved, duplicated, or be merged. Each proxy refers to a  
collection of revisions (one per language). The workflow concepts  
apply to proxies.
> The Id being generated in private-spaces, it would be possible that  
> at one point there will be a clash when the proxies are moved to  
> the common spaces, am I right?
It would, if there weren't further disambiguation systems in the  
workflow engine. For example, CPS allows resubmission of a document  
to the very same destination. In this case you have two proxies in  
the same section, a published one and a pending one. Of course they  
have different Ids (typically my_doc and my_doc_1). Same for the  
draft check-in/out system ("Créer une version" in the french UI)
>
> >The fact that it uses numbers for that purpose is coincidental (it's
> >not likely to change soon).
> >A cleaner way would be to implement you own logic using
> >container.hasObject() to check prior existence.
>
> I'm thinking of something like a global counter, somehow stored by  
> computeId, incremented for each document.
Then you wanna check CPSUid (checkout URL: https://svn.nuxeo.org/pub/ 
CPS3/products/CPSUid/trunk)
For an example usage, check CPSCourrier's cpsdocument_create_do and  
default profile.

A naive global counter is a database conflicts factory. CPSUid takes  
care of this.

Yours,

---------
Georges Racinet,   Nuxeo SAS
Open Source Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ and http://www.nuxeo.org/ - Tel: +33 1 40  
33 79 87






This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuxeo.com/pipermail/cps-devel/attachments/20070219/e4bcf8a0/attachment.htm