Architecture: evaluate scenarios for recurrence (specifying, storing state)

upiq / uu.task

Task management add-on for Plone

0 stars 1 forks source link

Architecture: evaluate scenarios for recurrence (specifying, storing state) #5

Open seanupton opened 9 years ago

seanupton commented 9 years ago

Example of recurring task

A "log" form (content item) that is appended to on a regular interval; unlike a form-per-interval approach where there is a 1:1 relationship between task-occurrence and content item, this is more tricky.
A "page" content item in Plone that needs monthly update by the assigned party.
Questions
Widget/UI: selecting recurrence rules.
Storing state.
Can we simply delegate to related/contained event (plone.app.event.dx) so that recurrence is not a re-invent-the-wheel problem?
- Or re-use widgets from plone.app.event ecosystem?
Indexing: plone.app.event has this problem solved to some extent, but I think we would want some kind of dedicated index (ZCatalog).

aclark4life commented 9 years ago

What is "the right way" to do this outside of Plone? I'd like to think (briefly) about the issue's requirements in general-web-application-context before trying to develop for Plone. Also would a review of p.a.event be helpful?

seanupton commented 9 years ago

Maybe the question could be distilled into:

(a) "How hard is plone.formwidget.recurrence to integrate into something other than plone.app.event?" https://github.com/plone/plone.formwidget.recurrence

(b) plone.app.event uses Products.DateRecurringIndex, which ought to be sufficient for indexing, which is a given if we are to support. OTOH, adding extra index to portal_catalog has overhead for all content, so we may just consider choosing to store, but not index the recurrence rule (as a "a RFC5445 compliant recurrence rule string" generated by the widget linked above). This might make the process that does email notifications heavier, but I think that is a reasonable cost at this point?

aclark4life commented 9 years ago

Got it, thanks. I'm going to assume the answer to a.) is "not hard" or at least "a reasonable goal" given that p.fw.recurrence looks "modern". I'm also going to assume that p.a.event is the fall-back choice if nothing else proves attractive or attainable, given that p.a.event has performance implications.

aclark4life commented 9 years ago

@garbas If you get inspired to do so, please add your thoughts about recurrence here.

upiq / uu.task

Architecture: evaluate scenarios for recurrence (specifying, storing state) #5

Example of recurring task

Questions