Philipp von Weitershausen wrote:
Jim Fulton wrote:
I've written an informational proposal stating the goal for
eliminating side effects, other than import, during the first phase
of configuration processing and generally minimizing first phase
processing. This will lead toward refactoring most existing
I don't expect this to be controversial, but comments are welcome.
You only mention one example for side effects (putting a global object
into a module and using them later), so I presume that the refactorings
will mainly be targeting this case.
This is really the only case (other than import) that I can think of.
I may be forgetting something.
Note that I also proposed moving as much processing into actions as
possible, to avoid doing unnecessary work when actions are discarded.
Do you already have specific plans on how to move the path
resolving/validating into the handlers,
I don't plan to move it into handlers. I plan t move it into
But you raise a good point. We were able to simplify handler
implementation using schemas to do much error checking upstream
of handlers. Now, by actually moving this downstream into the
actions, we'll end up putting more work on handler/action
implementors. This is a downside of the proposal.
1. When we made ZCML use schemas for upstream validation, we
made it *much* slower, so this was a mixed blessing.
2. Making it much easier to implement configuration handlers and
actions is important when there are many different handlers and
actions. This was true when we moved to schema-based
configuration but now many of us would like to see a smaller
selection of configuration options.
Note that we could probably provide some helper functions that provide
a similar level of automation downstream. For example, something like:
def importGlobal(id, info):
"""Try to import a global object for the given identifier
On success, the imported object is returned. On failure,
an exception is raised that includes information from the passed
configuration info object, such as configuration file name and
> and how to provide backward compatibility for 3rd-party directives?
I don't anticipate doing anything to break old directives, so I
don't see a backward compatibility issue.
Right now the proposal is quite high-level...
Yes, that's true. That's because it simply states a goal. It also
proposes that some specific directives be reworked, which should serve
to highlight issues/problems if any.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list