Hey,
Fabio Tranchitella wrote:
[snip]
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.
This:
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:
check_security_support()
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
successfully.
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
protectedFactory.
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.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
