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
