[Framework-Team] plone.app.event and it's portlets issue

David Glick (Plone) david.glick at plone.org
Sat Oct 5 15:51:47 UTC 2013


On 10/3/13 7:38 PM, Rok Garbas wrote:
> Quoting Johannes Raggam (2013-10-01 16:44:58)
>> Hey FWT!
>>
>> I need some advice on how to handle a problem with plone.app.event:
>>
>> In plone.app.event there is a "ploneintegration" submodule, profile and
>> setuptools extra. This is primarily needed because plone.app.event
>> registers the portlets.Events and portlets.Calendar under the same name
>> as plone.app.portlets. Therefore it needs to unregister them with
>> z3c.unconfigure for versions of plone.app.event, where those portlets
>> aren't removed - otherwise I get some zcml double-registration errors on
>> Zope startup.
>>
>> The "ploneintegration" setuptools extra has to be included manually for
>> versions of Plone < 5.
>>
>> Now, while integrating plone.app.event with plone.app.contenttypes,
>> which should work for Plone 4.2 and up, I don't want to depend on the
>> ploneintegration extra if possible. This pulls in the z3c.unconfigure
>> package, which has to version-fixed to 1.0.1 - otherwise it would
>> pull-in zope.component 3.8, which is not a Plone 4.x core dependency
>> version and not backwards compatible.
>>
>> Ideally I would get rid of the "ploneintegration" package.
>>
>> I see these options:
>>
>> 1) Releasing plone.app.portlets 2.5a1, where portlets.Calendar and
>> portlets.Events are already removed. This way, I can depend on this
>> version as a minimum requirement for plone.app.event and the portlets
>> double-registration issue isn't any more. Con: For other versions of
>> Plone 4.x, plone.app.portlets has to be maintained in it's 2.4.x branch.
>>
>> 2) Registering the portlets in plone.app.event under different names.
>> Pro: no zcml double-registration issues and no need to remove the
>> portlets.Calendar and portlets.Events from plone.app.portlets (altough,
>> they won't make much sense there when plone.app.event is merged into
>> Plone-core). Drawback: No seamless Upgrade-path and it breaks existing
>> installations (there are already some installations by different
>> integrators).
>>
>> 3) Including a hard-dependency on z3c.unconfigure in plone.app.event and
>> doing the unregistration if
>> plone.app.portlets.portlets.calendar.Renderer can be imported via a
>> zcml:conditional.
>>
>>
>> I prefer the first option, because it's quite straight-forward.
>> Can someone make a release, if you agree?
>>
>>  From pypi:
>> Package Index Owner: optilude, wichert, hannosch, esteele, maurits,
>> malthe, evilbungle, laurencerowe, davisagli, timo, vangheem
>> Package Index Maintainer: do3cc
>>
> i would go for option number 1.
>
>
>
Released!


More information about the Framework-Team mailing list