Hi Martin!

Martin Aspeli wrote:

- The procedure I have in mind depends on the ability to create customization snapshots. As a first step the setup tool would create this snapshot. In the next step it would combine all dependencies of that snapshot minus uninstalled extensions plus new extensions. The result is a profile that contains the latest data of all selected profiles plus the customizations from the snapshot. This profile would be used to reset the site.


Bearing in mind that my understanding is not completely solid, the option I
keep thinking we need is to say "run all import steps, but only for this one
extension profile". I have a workflows.xml and a types.xml and whatever else
in my extension profile for my product. I'd like to uninstall or re-install
or install workflows and types *for my product*, but I'm not interested in
evaluating every workflows.xml and types.xml in every active profile
everywhere (e.g. those that came with Plone or CMF or some other product),
lest they'd changed or I'd changed them and didn't want my changes stomped
on. Even though the actual import step is defined in another product (e.g.
CMFCore) I assume it'd be possible to simply not include steps for other
profiles?

The concept of import steps is confusing because it was invented before extension profile support was added. Originally an import step represented a piece of the profile. The handler property just provided the information which handler to use for this piece of the profile. That did no longer work with extension profiles. Now an import step just registers an handler.

Only the last selected profile is active. Normal import steps depend on configuration files and do nothing if the active profile does not contain related files. importVarious steps have to simulate that behavior by testing if they are already applied. If the import handlers follow those rules (CMF handlers do) only the profile *for your product* is applied. Running all steps just means that all handlers try to find related files in the active profile and apply them *if* they exist.

So your example should work right now. My proposal would mean that everything is reset, but without loosing customizations. So while the procedure would be much more expensive the result should be similar.

- I don't know if we really need a way to reset specific products. AFAICT the more common use case is to reset specific objects like tools. I'd prefer a tab on the object that allows to load preconfigured settings instead of using the setup tool for that.


This doesn't resonate with my experience from Plone, if I'm understanding
you correctly. I agree that some way of resetting individual tools may be
useful, but that's still very low level. If Joe Average downloads
CMFCrazyPollingProduct, he may install it, and need to un-install it
cleanly.

This is the normal uninstall procedure I described in my last mail.

He may also need to re-set it if he messed up its configuration or
maybe he's the developer and wants to test the effects of a clean
re-install.

Well. You can't always tell which customizations belong to which product. But after uninstalling a product customizations of related objects will fail if they no longer exist. So we if we uninstall and reinstall a product the effect should be similar to a reset.

Or, if the product is updated, he may need to re-run its
installation.

Do you mean you want to switch to the latest version of a specific profile but not of all profiles?

- While I hope we can get rid of importVarious it would be less dangerous to use if only complete profiles are applied to the site.


I suppose, except if I'm trying to just install product X, running some
(potentially destructive) importVarious from some other unrelated product
still seems risky.

It's still a hack. But I think we should focus on making writing handlers easier instead on making it easier to work around writing handlers. The changes I propose make it easier to write handlers. Writing handlers for PropertyManagers is already quite easy and generic support for Zope 3 schemas could be added.

Perhaps its FUD, but essentially re-creating a site each time you do an
incremental update (e.g. install a new product) seems really risky to me. A
bad product install can sometimes mess up that product - if you started
getting strange exceptions (and GS exceptions aren't always that easy to
debug, I've found) from somewhere deep within an unrelated product, that
could be pretty scary too.

I don't share those concerns. I'm more concerned about artifacts left behind by imperfect uninstall routines.


Cheers,

        Yuppie

_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to