On Monday 20 March 2006 10:47, Philipp von Weitershausen wrote:
> Stephan Richter wrote:
> >>>I am -1 on moving <implements> out of the class directive. I am
> >>> impartial on the factory subdirective, since I never use it. I think
> >>> factories are failed experiment, btw, but that's another story.
> >>>If <implements> is moved out than what's the point of having a class
> >>>directive in the first place.
> >>Making security assertions about the class. This would be the only thing
> >>that <class> would be used for, ultimately reducing its functionality to
> >>one thing.
> > Then why don't you call the directive "<secruity>"?
> Or <classSecurity>, because it's class-based. Good idea.
Oh, and that's not specific at all? I prefer my <class> directive (I agree
that <content> was an old, unnecessary relic) that allows me to configure
anything that I might want to configure about a class: security, interfaces
and maybe the usage (for example factory, utility, adapter). This way when I
see a class directive I know what I am in for. BTW, I currently really hate
when I have to do this:
I think it would be much nicer if I could do one of the two choices:
Of course it would be even nicer to specify the adapted and provided interface
as well in the directives, so I think this is a lost battle already. :-(
> > Or even better, get rid of
> > it altogether and have simple directives for "<allow>" and "<require>".
> Perhaps. Of course, practicality sort of wins here because we already
> have top-level <allow> and <require> directives for making assertions
> about modules.
Oh, so now you start talking about practicality? If we are practical, we would
not remove all high-level ZCML declarations. I am in total agreement that the
browser directives or any directive creating new types are doing far too
much, but this does not mean that high-level ZCML directives are bad.
> > I am still -1 on removing implements from the class directive.
> Why? I respect the vote but so far I haven't heard a reason for it.
In various responses I have given reasons. I just do not believe that a
minimal ZCML is the way of attracting new developers. Especially, since we
have no alternative.
> > I think they have another purpose. They group the declarations for one
> > thing together, which makes it easier to read.
> True. Which is why I would defend class/require and class/allow as
> subdirectives (instead top-level ones). The reason why I'm not defending
> class/implements is because I'd like to consolidate.
There is nothing bad about having an <implements> sub- and
top-level-directive. As you pointed out we do this already with the security
> Especially in Five, but I can imagine also in other projects, you'd like
> to declare interfaces on classes without configuring their security.
> Five invented five:implements for this. In Zope 3 this is not possible.
Yes it is. The class directives are additive. The following works and we do
this in SchoolTool:
<implements interface=".interfaces.IFoo" />
> Also, neither in Zope 3 nor in Five it's possible to declare an
> implemented interface on a function (I actually have use cases for this,
> of course I could deal with them differently, but a uniform way would be
I agree, this is a real limitation. So why not have something like that:
<implements ... />
<implements ... />
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list