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: <class class=".foo.Foo"> <require ...> ... </class> <adapter factory=".foo.Foo" trusted="true" located="true" /> I think it would be much nicer if I could do one of the two choices: <class class=".foo.Foo"> <adapter trusted="true" located="true" /> <require ...> ... </class> or <adapter factory=".foo.Foo" trusted="true" located="true"> <require ...> ... </adapter> 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 directives. > 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: <class class=".foo.Foo"> <implements interface=".interfaces.IFoo" /> <require ...> ... </class> <class class=".foo.Foo"> <implements interface="other.package.interfaces.IBar"/> </class> > 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 > nicer). I agree, this is a real limitation. So why not have something like that: <component class=".foo.Foo"> <implements ... /> </component> <component function=".bar.getBar"> <implements ... /> </component> Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com