Re: Re: CPSRelation/CPSComment abstraction branches

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