[Zope3-dev] Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  rdmurray+keyword+z3wiki2.24c5b9 at twirl.bitdance.com
    SMTP error from remote mailer after RCPT TO:<rdmurray+keyword+z3wiki2.24c5b9 at twirl.bitdance.com>:
    host twirl.bitdance.com [208.210.83.50]: 550 <rdmurray+keyword+z3wiki2.24c5b9 at twirl.bitdance.com>:
    User unknown in local recipient table

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev at zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1BBJ21-0005v3-7c; Wed, 07 Apr 2004 15:48:17 -0400
From: zope3-dev at zope.org (jim)
Reply-To: zope3-dev at zope.org
To: ;
Subject: [No more schema binding] (new) 
Message-ID: <20040407154817EST at dev.zope.org>
X-BeenThere: zope3-dev at zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev at zope.org>
List-Post: <mailto:zope3-dev at zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NoMoreSchemaBinding/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NoMoreSchemaBinding/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NoMoreSchemaBinding>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 07 Apr 2004 15:48:17 -0400
X-Spam-Status: OK (default 0.000)

No more schema field binding

  Status: IsProposal

  Author
 
    JimFulton

  Problem 

    There is a "feature" of schema fields that I really don't want to
    keep.   This feature is called "binding".  A field can be "bound"
    to an object.  This creates a new field instance, which is a clone of
    the original, that has a `context` attribute which is some object.
    The object *may*, for example, be an object that has an attribute that
    is specified by the field.

    Why do we need this?

    1. Field validation may need to look up (acquire) components.  For
       example, a permission field should allow only defined permission
       ids.  The defined permission ids are obtained by getting all of the
       names of IPermission utilities from the utility service.

    2. We may need to consider object identity, or a current object value.

       To illustrate this, consider a bumper car ride.  We have a system
       that let's us assign bumper cars to riders.  Clearly we should only
       assign unoccupied bumper cars.  But suppose that someone is already
       in a bumper car.  In that case, the car they are sitting in should
       be a valid choice for them, even though it is occupied.  To properly
       validate, or to generate a correct UI, we need to take into account
       the identity of the rider we're pickling a bumper car for.

    3. Perhaps there are other cases where we want to take context into
       account for some reason.  Perhaps allowable values for a field
       depend on data acquired from a folder.  This is hypothetical, but
       people I trust have told me that this is likely.

    Here's a non-reason for needing this: relationships between fields.
    Suppose we have two fields, `max` and `min`.  We want to assure that
    the `max` field value is not less than the `min` field value.  If we
    expressed this as a field constraint, we'd need to have an object that
    actually had the values.  It turns out that this is a bad idea.  Field
    constraints should only constrain values for that field, without
    regard to other fields.  Rather, we express constraints involving
    multiple fields using interface invariants.  Why?  Because otherwise,
    the validation of fields depends on the order they are processed.
    Consider the `max` and `min` case.  Do we put the constraint on `max`,
    or `min`, or `both`.  If you put the constraint on both, then you will
    be unable to make certain changes.  Suppose we have existing values 3
    and 4.   The user changes them to 5 and 6. If we check the constraint
    on `min` first, then the constraint will fail because the new `min` is
    greater than the old `max`.  If we check the constraint on `max`
    first, then we can't change the values to 1 and 2.  The saner approach
    is to either check invariants after the values have been assigned, or
    to apply the invariants to the full collection of input data.

    Reason 1, above, is addressed by:

      http://dev.zope.org/Zope3/FixedDefaultComponentLookup

    But we're still stuck with reasons 2 and 3.

  Proposal

    A. Validation

       Fields will provide a validation method that can be called to
       validate a value.  This method must do it's work without any
       context, because it won't have any.

       In Zope (or in applications that need context-sensitive fields)
       we'll validate by:

       - Calling the field validate method

       - We will also get multi-subscription adapters and ask them
         to validate the value:

       The logic would go something like this:

         >>> field.validate(value)
         >>> for validator in zapi.subscribers((field, context), IValidator):
         ...     validator.validate(value)


    B. Widgets

       Widgets will become multi-views:

         >>> widget = getMultiView((field, context), request, IInputWidget)

       So, in the bumper car example, when editing a rider, we'd use:

         >>> widget = getMultiView((field, rider), request, IInputWidget)

       But, when adding a rider, we'd use an adding object as the context::

         >>> widget = getMultiView((field, adding), request, IInputWidget)

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NoMoreSchemaBinding