Re: [Repoze-dev] Deform/Colander: allow empty non-String field in schema?
On May 27, 2010, at 3:24 AM, Chris McDonough wrote:
>
> This is an area that I'm not 100% confident about yet, so I'm glad
> you're stressing it a bit.
>
> FTR, this definitely won't work:
>
> SchemaNode(Integer(), required=False, allow_empty=True)
>
> Because a SchemaNode does nothing with either the ``required`` nor the
> ``allow_empty`` arguments. Instead, you probably meant to be passing
> these kwargs to the data type constructor ("Integer()"). I just made
> a change to Colander that will cause it to throw a TypeError if bogus
> keyword arguments are fed to the SchemaNode constructor, hopefully
> preventing future confusion about this.
I was grasping at straws and misread the docs; thanks for the alert that will
keep me honest next time.
>
> That said, although the ``colander.String`` type accepts an
> ``allow_empty``, there isn't any data type constructor that accepts a
> ``required`` argument. The ``required`` attribute of a SchemaNode is
> a computed property, derived from whether or not the node was given a
> default value, but types themselves aren't required or not-required,
> and neither a SchemaNode nor any particular type (Integer, String,
> etc) takes ``required`` as a valid kw argument.
It feels a bit unnatural to me to link 'required' to 'default'. Currently
supplying a default implies not-required, and not supplying default implies
required. What if I wanted a required field but wanted a default (e.g. a
users' name, or today's date)? Or the opposite: in my current case I want
fields to be optional, but don't want to force in an unrealistic number (e.g.,
number of things in a box = 0 or 24 or something else random).
I think it would be helpful to decouple these.
>
>
> I don't think you want to change the type.
Yeah, I'd prefer to use an Integer() if it's numeric, and not fake it with a
String() and special validator.
> I think this might be a
> deficiency in Colander or Deform, but I'd like to understand a little
> better before I make any particular change. So I'll try to state the
> requirements and the current state of affairs to make sure I make the
> right change:
>
> You want to make a field in a form "not-required". This implies
> that you don't want a little red asterisk next to the field title
> when the form is rendered, and when the form is submitted, you don't
> want the form to be re-rendered with an error message if no value is
> placed into the field representing the value. Instead, you want the
> form submission to be considered valid, and the data returned from
> the ``validate`` method of the form to contain a placeholder
> (default) value for that particular field. The placeholder value
> returned by ``validate`` won't necessarily be the same natural type
> as the field data type. For instance, you might want the
> placeholder value to be ``None``, while the type is an Integer.
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] Deform/Colander: allow empty non-String field in schema?
We're doing a BFG app with a MongdoDB backend, and the Deform stuff seems perfect for us, really enjoying using it so far. But I can't figure out how to make a field in a schema optional if it's not a String. (I've done this in Django model schemas where I can use the flag "null=True" and blank=True" on a non-string type). My reading of the docs says that setting a field's default=... it makes a field non-required, and default='' is fine for String types, but not so helpful for Integer, Date and other nonStrings. I've read doc mentioning flags: required=False allow_empty=True but allow_empty applies only to String and these seem to have no effect either. I'm looking to do something like: class StandardFields(colander.MappingSchema): manufacturer= SchemaNode(String(), default='') # not required obsolete_date = SchemaNode(Date(),required=False, allow_empty=True) length = SchemaNode(Float(), required=False, allow_empty=True) units_per_pack = SchemaNode(Integer(), required=False, allow_empty=True) but find these don't work: my fields are required to be set. Supplying a default value to indicate a non-required field, e.g.: units_per_pack = SchemaNode(Integer(), default=0) also feels wrong, since this will set the actual value to 0 upon storage to the DB. I am probably missing something in the docs. Perhaps I need a different approach for non-required fields, like making the schema a String but having a validator ensure they're my desired type if any value is provided on the form -- this seems a round-about way to do things. Any suggestions? Thanks. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG 0.9.1 / chameleon: render() takes exactly 1 non-keyword argument
Chris McDonough writes: > Hmm. Are you sure? Ala at the top level of your package: > find . -name "*.cache"|xargs rm -f > find . -name "*.pt.py"|xargs rm -f Yeah, just did the build out on a different box, did finds to make sure, did find...rm anyway. Same. I've gotten it to work with slightly older versions of chameleon, but see it's using the older .cache files. In my buildout.cfg I used a [buildout] 'versions' declaration and: [versions] chameleon.core = 1.0b32 chameleon.zpt = 1.0b16 I found it broke for me with .core at 1.0b33 and b34. Thanks. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] BFG 0.9.1 / chameleon: render() takes exactly 1 non-keyword argument
I've been plugging along with a routes and SQL based app, with BFG
0.8.0. I just changed my buildout.cfg to get BFG 0.9.1 -- and any new
versions of other packages -- but it's now throwing exceptions when
trying to render. I've removed any *.py, *.pyc and *.cache files from my
templates/ dir, but no help.
Paster starts up but when I try to access the top page, it bombs with
this excerpt:
Exception happened during processing of request from ('127.0.0.1', 57115)
...
File
"/usr/local/cshenton/Projects/koansys/accounting-0.4/accounting/accounting/views.py",
line 30, in home
master=get_template('templates/master.pt'),
...
File
"/usr/local/cshenton/Projects/koansys/accounting-0.4/eggs/chameleon.core-1.0b34-py2.6.egg/chameleon/core/template.py",
line 305, in cook_and_render
args, slots, macro, global_scope)
File
"/usr/local/cshenton/Projects/koansys/accounting-0.4/eggs/chameleon.core-1.0b34-py2.6.egg/chameleon/core/template.py",
line 182, in cook_and_render
return func(econtext, rcontext)
File
"/usr/local/cshenton/Projects/koansys/accounting-0.4/accounting/accounting/templates/home.pt.py",
line 33, in render
_metal.render(_tmp, _out=_out, _write=_write, _domain=_domain,
econtext=econtext)
TypeError: render() takes exactly 1 non-keyword argument (2 given)
Maybe I'm getting incompatible versions of various packages with my buildout:
[buildout]
find-links = http://dist.repoze.org/bfg/current/simple
http://pypi.python.org/packages/source/z/zope.sqlalchemy/
http://pypi.python.org/packages/source/t/transaction/
http://pypi.python.org/packages/source/S/SQLAlchemy/
http://pypi.python.org/packages/source/r/repoze.who/
http://formalchemy.googlecode.com/files/FormAlchemy-1.2.tar.gz
parts = bfg
develop = accounting
[bfg]
recipe = zc.recipe.egg
index = http://dist.repoze.org/bfg/current/simple
dependent-scripts = true
eggs= repoze.bfg
accounting
formalchemy
interpreter = python-bfg
Any suggestions?
Thanks!
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] unifying url dispatch and traversal
Chris McDonough writes: > Anyway, I don't really mind changing the urldispatch stuff radically at this > point; I'll fix the docs and our code and help anyone who needs it change > their > stuff. If I can make it bwcompat, great, but I'd rather break it now than > have > to live with it "forever". I've got an app that's routes-based and would need changing, but it's not in production yet so no biggie. I'd rather take the hit now and improve BFG while you can, rather than take the hit forever down the road. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
