I do think you are conflating form processing with db schema and the backend.
Decoupling the form processing from any form of backend is a pretty
important idea in my opinion.
>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
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
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.
How and what you store in the backend (what ever it is) is (if there
is one) is a whole different story.
> I'm not sure I agree with "data returned ... contain a placeholder (default)
> value" for optionals. Does it make sense to allow using required= and
> default= independently?
> I think I maybe be not thinking clearly enough about the distinction between
> the form processing and validation and marshalling to the appstruct, vs. the
> way (say) Django conflates schema and form and DB storage where a Integer
> field could be Null in their SQL DB. While I'd like to allow (say) an
> Integer field to be optional, I understand the marshaller can't set a python
> int to None -- it doesn't know or care that the backend DB would like to
> store it as NULL for SQL or omit the field for Mongo. I don't know if it
> makes sense for the marshaller to set an field whose schema is Integer to
> None if the field's marked optional and no value is supplied, or validate and
> marshal to an int if it is supplied.
> This seems it would be a common use case so perhaps I'm thinking of it wrong,
> or need to create subclasses like NullableInteger but that seems like I'd be
> reinventing the wheel a bit.
> Perhaps I'm just using it wrong; how are other users handling optional
> nonString fields?
> Thanks, Chris.
> Repoze-dev mailing list
Repoze-dev mailing list