Fabio Tranchitella wrote:
> I tried to implement my idea here:
> 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 -