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
_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel
