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

[johannes raggam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have now moved the dependency on plone.app.event from
Products.CMFPlone to the "Plone" package and removed it from
Products.CMFPlone.

I wanted to create a metadata.xml profile in "Plone", which installs
by default plone.app.event.at:default. But this doesn't work out,
since no other packge (Products.CMFPlone) imports it.

I think I drop my plan let Products.CMFPlone not depend on
plone.app.event and let Plone do this. We have to adapt
@@plone-addsite and @@plone-upgrade in P.CMFPlone.browser anyways to
let the user select the portal timezone, which is very important for
plone.app.event to work properly.

But before I backport everything back to P.CMFPlone,
plone.app.contenttypes should be merged in. It changes @@plone-addsite
and lets the user select which content type framework to choose, where
i can hook in and install wether plone.app.event.at:default or
plone.app.event.dx:default profiles.

plone.app.contenttypes is ready to merge, btw. Comes in another mail.


On 04/22/2013 11:44 AM, johannes raggam wrote:
> 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?
> 
> Thanks, Johannes
> 
> 
> _______________________________________________ Framework-Team
> mailing list Framework-Team at lists.plone.org 
> https://lists.plone.org/mailman/listinfo/plone-framework-team
> 

- -- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office at programmatic.pro
web:  http://programmatic.pro
      http://bluedynamics.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlF3EoUACgkQW4mNMQxDgAdGVACfQZgYiGf7eeOd1p0wOoRj4jvi
BroAoMTSP6XY4kRXirbBy4HM0RY3SemK
=L1LZ
-----END PGP SIGNATURE-----