Hi,
Sorry I wasn't clearer: I meant an API conversion guide
(rtool.getRelationsFor to graph.getSubjects, etc.).
Oh ok, not there is no such thing but I'm sure looking at the new
interface (CPSRelation/interfaces/_IGraph.py) will help.
I realized after hitting 'Send' that __getitem__ was enough:
<tal:block define="graph here/portal_relations/?GRAPH_ID">
<tal:block replace="graph/title_or_id" />
</tal:block>
(i.e., getGraph seems superfluous)
So that's a security hole :)
Are you using CPSRelation for a custom need? If so, I would be pleased
if you could explain your use case, see if the product addresses your
needs correctly.
I've got two use cases:
1. Better internal link widget, linking documents by docids instead of
paths
2. Relations between documents (such as 'is based on', 'supercedes',
'mocks', ...)
The first case I've implemented and use, the 2nd one not yet. In both,
there's a difficulty because the source document may not exist yet; is
this where asynchronous graphs help? (I'm working around by using a
specific workflow)
Not really, asynchronous graphs are used to avoid problems when using
non transactional backends: relations are added/removed at the end of
the Zope transaction. This is a problem you won't have if you're using
IOBtree graphs as they are transactional.
Note that you will always have a problem to create relations between
documents that may not exist yet as long as you keep on using the
document docid as an identifier: it is only created and linked to the
document after the document creation. So I suggest you use another
unique identifier for your documents to make it easier, keeping its
value in the document metadata.
Maybe you would like to have a look at the CPSUid product to do so:
https://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSUid/trunk
The new API looks friendlier to the 2nd use case, where users will be
able to create new relations without the need for an explicit reverse one.
I think the abstraction that is now available makes it a lot easier to
handle relations in CPS, I hope you will agree.
Fully agreed. Though I don't know how to use it yet :-)
For instance, where my old code contained
reltool = getToolByName(ob, 'portal_relations')
docid = int(ob.getDocid())
...
for rpath in rpath_list:
proxy = ob.restrictedTraverse(rpath)
reltool.addRelationFor(RELATION_GRAPH_ID, docid, relname,
int(proxy.getDocid()))
it should be converted to use CPSRelation.node.* and such, right? (BTW,
are these available to restricted code?)
Ok so here is the trick that make it easier to handle relations now,
imho: now Zope 3 adapters may be used to convert a document to its
equivalent resource to be used in relations.
I would translate your code as is:
reltool = getToolByName(ob, 'portal_relations')
graph = reltool.getGraph(RELATION_GRAPH_ID)
statements = []
subject = IVersionHistoryResource(ob)
predicate = Resource(relname)
for rpath in rpath_list:
proxy = ob.restrictedTraverse(rpath)
statements.add(Statement(subject, predicate,
IVersionHistoryResource(proxy)))
graph.add(statements)
This may not be available to restricted code, note that you can always
make them available if needed, take example on:
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSCore/trunk/AllowModules.py
If you would like to handle new kind of resources (using your specific
unique identifier for documents), you can define a new type of resource,
and provide corresponding adapters for CPS documents/proxies.
Note that if don't want to use adapters, and have a straight access to
the document docid for instance, you can always do:
subject = VersionHistoryResource(docid)
or even:
subject = PrefixedResource('docid', docid)
Using adapters allows you to define fine-grained resources playing with
the graph configuration.
For examples on how to handle relations, please look into the tests
folder, especially:
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSRelation/trunk/tests/test_node.py
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSRelation/trunk/tests/test_statement.py
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSRelation/trunk/tests/test_iobtreegraph.py
You also have a live example on how relations are handled in the
CPSComment product:
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSComment/trunk/commentresource.py
http://svn.nuxeo.org/trac/pub/browser/CPS3/products/CPSComment/trunk/commenttool.py
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
