[Framework-Team] plone.app.event integration issues

David Glick (Plone) david.glick at plone.org
Mon Apr 22 17:27:12 UTC 2013


On 4/22/13 2:44 AM, johannes raggam wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear FWT people,
>
> I want to follow up the discussion from the last FWT meeting about
> plone.app.event's integration issues.
>
> Although plone.app.event is developed with least external dependencies
> pointing to it and therefore it is de-installable, we should still
> ship with an Event type installed by default for Plone 4.4. I think
> this default Event type should still be the Archetypes based.
>
> This could still be the ATContentTypes ATEvent, with an option to
> install plone.app.event's ATEvent or the Dexterity Event instead.
> Plone.app.event provides the "ploneintegration" profile for this. If
> we want to go this way, we should revert the merges on Plone core
> packages which werde done some weeks ago (CMFPlone, ATContentTypes and
> plone.app.portlets).
>
> The other option is to completly replace ATContentTypes ATEvent with
> the plone.app.event one (which I prefer...). For this, we have to
> migrate old ATEvent types to the new ones (a roughly tested migration
> step is included) - mainly to add the timezone, wholeDay and
> recurrence properties. I tend to favor this option, altough there
> might be some risks involved, which I cannot see at the moment.
>
> If we choose the second option, I would integrate plone.app.event in
> the "Plone" package instead of Products.CMFPlone and create a profile
> there (there isn't one at the moment). The Plone package was meant as
> a default Plone distribution. If we put it there, people can still
> build applications with Products.CMFPlone without having to depend on
> plone.app.event, if they don't need it.
>
> What's your opinion on this?
>
I prefer the second option.

If people have created custom subclasses of ATEvent, what will happen to 
them?
David


More information about the Framework-Team mailing list