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
configuration directives.

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
actions. :)

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.

I'll note:

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
      line number.

> 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  
Zope Corporation
Zope3-dev mailing list

Reply via email to