New addon: collective.relationhelpers to manage, create, export and rebuild relations

pbauer · May 30, 2020, 7:07am

Yesterday I released collective.relationhelpers:

It has useful methods to deal with relations and a form that rebuilds all valid relations. That's especially usefull if the relation-catalog has references to broken objects (e.g. after you migrated from AT to DX).

@ericof suggested we should add link_objects and get_relations to plone.api.

jaroel · May 30, 2020, 10:46am

Awesome!

re plone.api, I've specced something a while back: https://github.com/plone/plone.api/issues/223

pbauer · June 1, 2020, 8:28am

I would not want to support Archetypes any more. Would that be acceptable for plone.api?

I wrote collective.showreferences a while back to show incoming and outgoing references for DX and AT:

github.com

collective/collective.showreferences/blob/master/src/collective/showreferences/browser/references.py#L38


    from zc.relation.interfaces import ICatalog
    from zope.component import queryUtility


import logging


logger = logging.getLogger(__name__)




class ItemReferences(BrowserView):


    def references(self):
        """ Return a dict with all refs and backrefs fo the current object.


        Links are html-links in richtext-fields. They are stored in the
        relation_catalog when linkintegrity-support is enabled.
        For archetypes-objects that works ootb.


        For dexterity-object two additional packages need to be installed
        and their respective behaviors need to be enabled:


        1. plone.app.relationfield adds support for relations to arbitrary

jaroel · June 1, 2020, 8:51am

Personally, I would not be sad to not have AT support.

Please note that I've added the issue in 2015 and I haven't seen (any?) questions and/or requests for an implementation of it - besides a "it would be nice".

If someone is interested in developing, please reopen the linked issue.

alert · June 1, 2020, 9:14am

What about having a plone.api v2 which is AT free for Plone 6 and above?

A big plus if plone.api v2 should support 5.2 without AT (i.e. travis build should pass) but the default version shipped with Plone 5.2 should still be plone.api 1.x.

That would cover all the current versions that work with Python 3.
If somebody wants to use plone.api 2.x with Plone 5.2 he just has to add a pin to the buildout.

If there are still AT users out there they can stay with plone.api 1.x or do the extra effort to backport the changes to work with AT.

I would not even put in the game Plone versions < 5.2.

Another option is to go the hard way and also remove completely the support for Python2 for plone.api v2.
But that might be too early, see https://plone.org/download/release-schedule.

Open for discussion

pbauer · June 1, 2020, 10:03am

I missed that proposal then and I would have loved to have it

iham · June 1, 2020, 1:35pm

love the idea and also the plans for adding relations to plone.api

pbauer · July 1, 2020, 9:06am

I wrote a PLIP about that:

I also refactored the api of https://github.com/collective/collective.relationhelpers to make it even easier to work with it:

return objects by default, optionally return a dict by relationname
check view-permissions by default
add convenience-methods relations, backrelations, unrestricted_relations and unrestricted_backrelations
add convenience-method relation for relationChoice fields that only returns one object, not a list
allow to query for multiple relations (especially usefull in combination with as_dict)