On Fri, 2010-05-28 at 07:25 +0800, Tim Hoffman wrote:
> >From the point of view of the form definition, I think you need to be
> able to define some type
> of sentinal value that indicates a field is empty, but valid if it is
> not required.
> I think it would be a mistake to assume that default implies either
> required or optional.
> It is quite feasible to have requirements where a default value is
> provided for a form field
> but that no value is ultimately required.  And its very common to have
> required fields
> with no obvious default value.
> So I would personally argue that having default value, and that a
> field is required or not be independent of each other.

I agree with how Tim just characterized this.  I'm still trying to
figure out what the best way to spell it.

My current idea is to:

- Define a special "null" sentinel value.

- Change the type definitions and widget definitions to do something 
  sensible when they see a "null" during serialization and
  deserialization. (e.g. "n = SchemaNode(default=null)").

- Add a required= flag to SchemaNode, e.g. field = SchenaNode(Integer(),

- Decouple the meaning of default and required.

However, that leaves this corner case, which I'm having a difficult time
trying to reconcile:

  n = SchemaNode(Integer(), default=1, required=True)

I *think* this means that the "first rendering of the form will display
a 1 in the field, but that an empty value will not be tolerated in any
resubmission thereafter".  However, I'm not sure if that definition
matches any sensible use of Colander outside its use as a schema system
for Deform, and it needs to, so I'm still chewing on it.

- C

Repoze-dev mailing list

Reply via email to