[Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Martin Aspeli]

Hi Raphael,

>>> Of course we still need to fix the current Archetypes mechanism to work
>>> with CMF 2.1. As we havn't deprecated it yet, we cannot brake it.
>>>
> With respect to just putting something (the ftis) into the ZODB in order
> to keep things working at a minimal level this shouldn't be hard and
> I hope to be able to commit a fix later today on the plip branch
> (just augmenting what intallTypes does itself).

Great.

> With respect to continuing support for all the additional Zope 2 magic
> which to my knowledge is mainly needed to support the ZMI, it's more
> cumbersome but if we agree that we don't need that - fine (who of you ever
> added an fti from an initialized but uninstalled product or re-added a
> deleted fti not via re-install but in plain ZMI? If we can skip support
> for that, then I think this is a no brainer)

You can do that? ;-)

>>> So for Plone 3.0 (or maybe 2.5.2 as well) we would have both traditional
>>> AT-based and new GS-based installation support with deprecation warnings
>>> for the AT-based one.
> maybe we don't even need to deprecate the "old" appoach?
> As long as we can take care ourselves to support it?
> 
> And first and foremost: one of the main reasons why AT became
> so popular is that it frees developers from writing most of the
> Zope/CMF boilerplate code for products.
> Now if this boilerplate code has to change, AT should change
> but ideally the add-on developer, aka the "AT user", wouldn't
> even notice (I know this is day-dreaming ...)

I think this is the right attitude to keep, definitely.

> One further remark wrt Martin's concerns about GS:
> in addition to what has been rightly said about active
> profiles I think there is a further detail worth knowing:
> profiles can be applied in purge mode (remove and recreate)
> or non-purge mode (things that are already there are left
> alone). IIRC at least extension profiles are run in non-purge
> mode per default. Others correct me if I'm wrong.

I think that's right yes. Thanks to Rob for clearing up my initial 
misconception (I blame the portal_setup UI, personally ;-). If QI can 
handle (somewhat braindead) uninstall and we can still have regular 
uninstall methods, and we don't kill the old way of installing FTIs with 
installTypes(), then I think we're far along.

Martin