Gary Poster wrote:
> > Dominik Huber wrote:
> >>> Now that this proposal has been dealt with, I will turn my focus of
> >>> attention to
> >>> http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives.
> >> I like those simplifications, but I have two little objections...
> > The class/implements subdirective is debatable because putting an
> > interface on a class might be considered some sort of policy. So I
> > don't
> > feel too strong about it.
> Strong -1 on removing class/implements.
> We use this frequently to apply policy from one package to a content
> object in a second unrelated package, from within a third package
> that depends on both.
Sounds like an interesting usecase. I definitely agree about marker interfaces
being on/off switches for certain policy. My motivation for removing
class/implements wasn't that I didn't see the usecases. It is that the class
directive as it is now mixes one kind of policy setup (security) with another
kind (marker interface).
Perhaps we shouldn't get rid of class/implements but just move it out of the
class directive into its own one. Then it would also possible to make more
implements calls without having conflicts on the class directive. Making
security assertions only needs to happen once, putting marker interfaces on a
class could happen more than once (your usecase almost seems to suggest it).
Also note that Five has a five:implements directive which works exactly like
the top-level implements directive I'm suggesting to create in place of
class/implements. It is known to be used more than once on the same class.
I updated the proposal accordingly, though so far only at
since zope.org seems to be down right now.
> I'll miss class/factory, but agree that it is an example of the magic
> you are trying to remove.
Yup. Plus, it wouldn't make much sense removing factory and not class/factory.
This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list