FWIW, in repoze.formapi, I originally had the same constraint – no required fields – but we later introduced it because of these reasons exactly.
See http://pypi.python.org/pypi/repoze.formapi/0.5.0 ("required fields") \malthe On 28 May 2010 02:25, Tim Hoffman <zutes...@gmail.com> wrote: > Hi > > 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 > 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. > > How and what you store in the backend (what ever it is) is (if there > is one) is a whole different story. > > Regards > > T > > > > >> >> 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@lists.repoze.org >> http://lists.repoze.org/listinfo/repoze-dev >> > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > -- Malthe Borch Technical Advisor UNICEF Uganda +256 (0) 703 945 965 _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
