On 11/15/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
Hash: SHA1

Alec Mitchell wrote:
> Tres,
> What are your feeling about this?  Is there a reason not to jettison
> the toolset registry, other than backwards compatibility?
> Thanks,
> Alec
> On 11/14/06, yuppie <[EMAIL PROTECTED]> wrote:
>> Hi Alec!
>> Alec Mitchell wrote:
>>> So I've recently run into a bit of a problem involving the extension
>>> profiles and the toolset registry.  The issue is that if I install an
>>> extension profile that overrides one of the tools from the base
>>> profile, then switch back to the base profile (but not run any steps),
>>> then switch to another extension profile that provides a toolset step
>>> (which has no mention of the tool overridden in the first extension
>>> profile), the tool from the base profile will replace the tool from
>>> the first extension profile, even though the base profile was never
>>> re-installed and the second extension profile makes no mention of this
>>> tool.
>> I personally just ignored the toolset registry because I never needed it
>> and it never did get in my way.
>> The issue you describe is annoying. Instead of working on a fix I'd
>> prefer to rip the toolset registry out. But maybe Tres knows why the
>> toolset registry exists and why it is still useful.

I don't think the registry is redundant:  it enables some
"bootstrapping" that would otherwise require writing procedural code.
Essentially, the overall "meta-profile" is defined via the three
registries:  required / forbidden tools, import steps, and export steps.

IIRC, extension profiles are not properly *supposed* to override the
base profiles tools, precisely for this reason.  They are not really
designed to be "reversible" either.

The "add-on" use case people are trying to shoehorn into extension
profiles is not really appropriate, especially if "reversion" becomes
part of the deal.

In this case reversibility is not the issue, and I don't think we're
expecting it.  The problem is that the tools that are loaded when a
toolset step is run are not those specified in the current active
extension profile, but rather a combination of all of those in every
profile that has ever been made active, regardless of whether the
steps of that profile were imported or not.  This seems pretty
inconsistent with the way that all the other import steps work.
Perhaps the toolset registry should only be updated when the toolset
step is run, not whenever a profile is made active?

Add-on products almost always make changes to skins, actions,
properties, registries, and other things under the purview of GS.  It
would be a shame if such products can't easily use the very convenient
mechanisms that GS provides to do so.

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

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

Reply via email to