Fabio Tranchitella wrote:
> I tried to implement my idea here:
> svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security
> This is a quite intrusive change, so please take it as a "suggestion" and
> not as a real proposal: is this the right approach? 

That's more or less what I have in mind. The suggestions are just about 
trying to make it prettier.


                 if not SECURITY_SUPPORT:
                     raise ConfigurationError("security proxied components 
are not "
                         "supported because zope.security is not available")

could simply become a function you can call:


That'd be far less repetitive code.

I'd also place everything you put in the 'else' branch for the import 
error check into a separate module. This way you don't have to define a 
lot of stuff on the top level. When you see something from this module 
in use, you *know* check_security_support() should have been executed 

Further improvements might be possible by an approach where instead of 
doing a lot of conditional checks everywhere, you define the things that 
do need security in such a way that they just proceed gracefully without 
security as well (or raise the appropriate errors).

For instance, proxify() might simply not do anything, the same with 

> I did not (yet) write
> all the tests needed (and I don't like the idea of duplicating the tests in
> zcml_conditional.txt, to be honest).

I think we need to try to separate security-related tests from the rest 
of the tests, and test that they fail with the right errors if 
zope.security is not present and do the right thing when it is.

It would also be nice to be able to run the other tests with or without 
zope.security - the result should be identical.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to