Re: CPSShema and managment of relations between objects

Santi Camps a écrit :
> Sure.   The main reason to work with CPSSchemas is that I want an
> administrator be able to define relation fields, just saying "the
> field customer of the invoice schema will be a reference to an object
> with portal_type='Customer'  "    CPSRelation is probably a better
> way, but needs some programming on each new type of objects using
> relations, and doing it in CPSSchemas allows an advanced user to
> define new types an relations on its own.

I'm not sure I understand your need, maybe it's just a user-interface 
issue ?

For CPSComment that was not necessary, but I've been thinking of making 
it possible to manage relations using CPSSchemas fields, schemas, 
widgets and layouts.
I even did some changes in the code to be able to define a storage 
adapter specific to a schema. In my mind, a new type of schema, 
inheritating from base schema class, would be used to commit (via a 
standard datamodel) relations to graphs instead of setting attributes to 
a document. Standard fields, widgets and layouts could be used.

For the moment I did not really have this need. I sometimes use the 
standard layout/schema mechanism to describe a relation to be set, but I 
never commit any datamodel: instead I call a specific API that will do 
the job.

Some of the issues is that a node is really described by its type 
(resource, literal... etc using the RDF jargon), sometimes its prefix 
(e.g its RDF namespace) if you'd like to handle a specific resource, and 
then its value. I did some job to be able to address these problems in 
the abstraction branch: making the interface between Python classes and 
RDF nodes is not so easy and requires configuring CPSRelation graphs 
carefully.

Some other issues would need to be addressed because updating a relation 
  is really a "remove old relation" and *then* "add new relation" 
operation for RDF graphs. So I guess the datamodel should also remember 
the old values to be able to delete them in the graph.

And last but not least, sometimes relations are not managed in a 
document context, so it would not make sense to define schemas/layouts 
for relations management in a document type definition.

>> When comments or commented documents are deleted, Z3 events allow to
>> delete now useless relations.
> 
> I have implemented the opposite feature.   When a dead document (with
> no proxies) is related with a live document, at least last revision of
> the document should remain in the portal_repository, so its
> information could be viewed from the live document.    When all
> referencing objects are also dead, then the documents could be purged
> from the repository.

Yes, that makes sense too. Z3 events are really powerfull to address 
this kind of issues :)
I guess you could query a CPSRelation graph, and see if a resource is 
still in the graph before allowing it to be deleted.

Regards,

-- 
Anahide Tchertchian, Nuxeo
Mail: [email protected] - Tel: +33 (0)1 40 33 71 60
http://www.nuxeo.com - http://www.cps-project.org
_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel