[CPS-devel] Re: CPSRelation/CPSComment abstraction branches

[Yves Bastide]

Anahide Tchertchian wrote:
> Hi,

Hi!

>> * upgrading CPSRelation results in broken (IOBTree, at least) graphs
> 
> Yes, sorry for that but the new products define completely new objects 
> with a new api, CPSRelation has been completely refactored so no 
> compatibility was kept.

No worry.

> 
>> * Is there a conversion guide available?
> 
> Unfortunately no. CPSComment was the only product actually using 
> CPSRelation, and it has never been packaged in a CPS release so we 
> assumed that nobody would want to change the products *and* keep 
> existing data.
> It should be quite easy to export the Btrees content using the old 
> products, then replace by the new products, and then reimport data.
> Please tell if you need guidance to do so, I would be glad if you could 
> make this contribution.

Sorry I wasn't clearer: I meant an API conversion guide (rtool.getRelationsFor 
to graph.getSubjects, etc.).

Regarding a data conversion tool, this looks trivial, as you say. Anyway I'll 
probably keep using the old branch for the (frozen) project having existing data.

>> * RelationTool methods generally need the ManagePortal permission. E 
>> g., AFAIK,
>>
>>     relids = rtool.getRelationsFor(GRAPH_ID, docid, relation)
>>
>> is now:
>>
>>     graph = rtool.getGraph(GRAPH_ID)
>>     relids = graph.getSubjects(relation, docid)
>>
>> But while getRelationsFor only needed the View permission, getGraph 
>> needs ManagePortal
> 
> Yes, tool methods are no longer available, because it looked like an 
> unnecessary api duplication. If you really need access to the graph in 
> restricted code, I suggest you write the appropriate util methods to do so.

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)

> 
> 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)

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?)

> Regards,

Same,

yves