[Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0

[Phillip J. Eby]

At 11:04 AM 8/27/00 +0100, Steve Alexander wrote:
>
>I have been putting CatalogTriggers as DataManagers directly in
>Specialists.
>

And this *works*???  None of the "Acquired ... Provider" classes supported
forwarding to an acquired trigger, as far as I can recall.  The fact that
it's so bloody awkward to forward to acquired providers is part of why I
think they should be dropped.

Hmm...  looking at source code...  aha!  Okay, so "Link to Parent Data
Plug-ins" provides linking to triggers.  I'd forgotten about that,
obviously.  Dang.


>This seems to me the obvious place to do some triggering action that
>applies over all the Specialist's racks, but which has nothing to do
>with storage.

Yes, it is.  But it also adds to new user confusion, and leads to a bunch
of otherwise-unnecessary code complication.  In particular, Specialist
wouldn't need to be a DataManager when it's really only a PlugInContainer.


>I don't yet use SkinScript. However, I imagine there are a number of
>uses for Triggers that apply at the level of abstraction of a
>Specialist.

Would it be an undue hardship to copy these into all the relevant racks or
customizers, until there is a feature to allow inclusion from another rack
or customizer?


>Please think about keeping the feature, if it doesn't make things too
>complicated.

Basically, the problem is that I am trying to decouple delegation
interfaces from the ZPatterns core.  That is, I'm trying to make it such
that DataManagers don't have to know about all the possible things that can
be delegated to Data Plug-ins.  That way, as additional plug-in
capabilities are added, such as content providers and local role providers,
the DataManager class doesn't change, since it's just an intermediary for
*finding* those providers, and giving dataskins certain persistence-related
services.

Unfortunately, using items that link to acquired providers with any kind of
filtering means that the link itself must provide some form of the
interface which is being delegated, which means that the link must know
about all possible interfaces.  :(

Now, I can provide *unfiltered* linkage by direct delegation, but this
would mean dropping the ability to selectively take only certain attributes
or sheets from the parent.  But I suppose that, compared to dropping the
capability to acquire altogether, this might be preferable.

Hmmm.  Let me think about this.