[Zope3-dev] Reducing the Amount of ZCML Directives ready for review

[Stephan Richter]

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