[Zope3-dev] Re: Zope Configuration Processing and Side Effects

[Jim Fulton]

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
>> At:
>>
>>   http://dev.zope.org/Zope3/ZopeConfigurationProcessingAndSideEffects
>>
>> 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

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org