[Product-Developers] modules using collective.subscribe ?
thomas.desvenain at gmail.com
Fri Jul 13 10:29:09 UTC 2012
Thank you for your answer. Indeed collective.inviting helped me to use
collective.subscribe and make everything i needed on my usecase.
I'm amazed by the work you have done on collective.subscribe.
This is very useful, elegant and powerful. I hope it will become a standard.
(I think i will rewrite using this api some other stuff with similar
cases, where our implementation suffers some limitation -
collective.favorites and collective.local.addgroup for example)
On Fri, Jul 13, 2012 at 12:06 AM, Sean Upton <sdupton at gmail.com> wrote:
> Hi Thomas,
> collective.subscribe is potentially useful in concert with
> collective.inviting (even if you ignore the UI bits from
> collective.inviting). A few caveats and issue to be aware of:
> 1. I implemented the storage for the subscription catalog (indexes per
> named relation of principal<-->content -- as subsciber-signature-tuple
> to UIDs) are stored in a local utility when used by
> collective.inviting. I am not happy with the risks associated with
> this, and may soon change this to use annotations on the portal to
> store the BTrees and replace the local utility with either an adapter
> of the portal object or as a global adapter that uses getSite() to get
> a venue for storage. This has been the major blocker from me
> releasing the uu.inviting package to PyPI (only on github at the
> moment). collective.subscribe itself has no pre-disposition as how
> the persistent components for indexes are registered, only that they
> are persistent objects somewhere inside a ZODB database.
I agree with you (using annotation on portal instead of local utility
If you do that, please write an upgrade step to migrate values.
By the way, i think that collective.subscribe is ready for a release now.
> 2. The "signature" tuple storage format in collective.subscribe is
> flexible enough to support both site members and guest users --
> usually these are stored using a signature like ('email',
> 'me at example.com') versus ('member', 'myuserid').
> 3. Right now, the subscription that is indexed always assumes there is
> a content item (or a UID-addressed object of some sort) that a
> subscriber is subscribed to. Other types of relationships really are
> not supported (if you need something more flexible, maybe consider
> zc.relation-based solution).
I'm okay with that
> On Thu, Jul 12, 2012 at 8:22 AM, thomas desvenain
> <thomas.desvenain at gmail.com> wrote:
>> I plan to use collective.subscribe as a dependency of a module i'm
>> writing about subscribing users to digest notifications.
>> collective.subscribe looks very good and very useful, but i'd like to
>> see another product that uses it.
>> do you know online examples of module using collective.subscribe as a
>> dependency ?
>> Thomas Desvenain
>> Téléphone : 09 51 37 35 18
>> Product-Developers mailing list
>> Product-Developers at lists.plone.org
Téléphone : 09 51 37 35 18
More information about the Product-Developers