[Zope-CMF] Re: [dev] CMFSetup roadmap?

[yuppie]

Hi!


Martijn Pieters wrote:
> There are two usage scenarios for add-on Products:
> 
> 1) Using add-on Products plus CMFSetup for a custom site setup you want
>    to reproduce easily.
> 
> Site builders can create the correct profile files already with the 
> current CMFSetup tool, by including add-on Products import and export 
> steps by hand. It would be handy if there was a TTW UI to add steps so 
> that one can run an initial export to create a profile one can check 
> into CVS.

Yes. And I hope writing new import/export handlers will become easier in 
the long run.


> 2) Including add-on Products' tools and their setup in a default
>    installation of a CMFDefault Site (or a Plone site if Plone chooses
>    to use CMFSetup)

This is the scenario I had in mind and what's needed to replace the old 
setup machinery. Add-on products should ship with XML files, not with 
install scripts, FTIs and preconfigured tools.

> My original CMFSetup product used a runtime registry to manage 
> dependencies and add-on steps centrally. In the CMF 1.5 refactoring, 
> this registry has been replaced by 2 XML files in the profile, which 
> makes it hard for add-on products to add their steps by default for easy 
> alteration of a default CMFsetup.
> 
> My original CMFSetup also included support for multiple layers that 
> could be run in succession; each step would loop through the layers and 
> apply the configurations. Extra products could then add a layer for the 
> 'tools' install step that just included their own new tools and 
> configurations, or even undo default configuration changes done by 
> earlier layers.
> 
> If add-on products want to enable installation into a stock CMF Default 
> site (or a Plone site if Plone were to use CMFSetup), then I think that 
> supporting layering again would be the best way to go; additional 
> products would only have to include additional XML files for the changes 
> they need to make for their default setup. A central registry could then 
> manage what profiles are available, and what layers are enabled.

That sounds reasonable. But if I did get Tres right, there was a reason 
why he didn't check in that code. I just did never understand how things 
could work without a machinery like that.


Cheers,
	Yuppie