[Zope-dev] zope.security changes

[Martijn Faassen]

Hey,

Dan Korostelev wrote:
[snip]
>>
>> What about the other use case of <class>, i.e. declaring implemented
>> interfaces, as in
>>
>>  <class class=".foreignmodule.SomeClass">
>>    <implements interface=".interfaces.ISomeInterface" />
>>  </class>
> 
> +1. That's kinda strange to have it in zope.security.
> 
> I think, the better place to move zcml directives is zope.component,
> as it already depends on zope.security for the zcml support and the
> "class" directive also has component-related "factory" subdirective
> which declared in zope.component.

It's true <class> isn't purely about security. It's not purely about 
component configuration either, though.

Most of what 'class' is about is security-related, so it's using a lot 
of stuff in zope.security. If you look at the implementation, I think 
people would agree it's doing more security manipulation then it's doing 
component configuration. And I think we can at least agree zope.security 
is at least an improvement in location compared to their scattered 
implementation throughout zope.app.component and zope.app.security.

So, I don't think we'll be moving <class> (and then <module>) into 
zope.component this week during the sprint, and not just because it'd 
distract us from our main goal to reach layered dependencies.

I believe that zope.component relying on zope.security (if indeed [zcml] 
is enabled) is actually something that could be avoided if we moved the 
ZCML directive implementations from zope.component entirely. When you 
install zope.component without ZCML support, you get a reasonable 
dependency list actually installed. When you do use the ZCML dependency 
it starts pulling in a lot more, including quite unreasonable stuff like 
zope.publisher and zope.traversing. See this for more information:

http://plope.com/Members/chrism/pluginizing_an_app

I believe it'd be nicer to extract any ZCML related stuff from 
zope.component at some point and put it into zope.componentzcml or 
something like that. We could then decide to move the <class> and 
<module> directives in there as well.

Regards,

Martijn