Re: [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. 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. 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. 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. I don't think you want to change the type. 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. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue147] Deform default form action . submits to parent folder
Chris McDonough chr...@plope.com added the comment: Thanks, I've changed it to use '' rather than '.' on the trunk. -- status: unread - resolved __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue147 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] routing exception when run as wsgi application
Hi, That doesn't appear to be the full traceback. The most important bit is at the end. Could we see that part? - C On Wed, 2010-05-26 at 10:02 +0800, Yuan HOng wrote: Hi, I have an application with the following routing configuration: route path=wishlist name=wishlistjson header=Content-Type:application/json;* xhr=true factory=.order.wishlistview.wishlist_factory view=.order.wishlistview.WishlistJSONView view_renderer=json / route path=wishlist name=wishlist xhr=true factory=.order.wishlistview.wishlist_factory view=.order.wishlistview.WishlistView view_renderer=order/wishlist.pt / The same url path is used for both JSON request and normal ajax html load. The configuration works fine when run with paster. However when run with mod_wsgi + apache2, I got the follow exception in the Apache error log: [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] mod_wsgi (pid=1818): Exception occurred processing WSGI script '/home/hong/hm.web/trunk/hm.web.wsgi'. [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] Traceback (most recent call last): [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/Beaker-1.5.3-py2.6.egg/beaker/middleware.py, lin e 152, in __call__ [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] return self.wrap_app(environ, session_start_response) [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/repoze.tm2-1.0a5-py2.6.egg/repoze/tm/__init__.py , line 23, in __call__ [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] result = self.application(environ, save_status_and_headers) [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/repoze.bfg-1.3a3-py2.6.egg/repoze/bfg/router.py, line 76, in __call__ [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] info = self.routes_mapper(request) [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/repoze.bfg-1.3a3-py2.6.egg/repoze/bfg/urldispatch .py, line 54, in __call__ [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] if preds and not all((p(None, request) for p in preds)): [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/repoze.bfg-1.3a3-py2.6.egg/repoze/bfg/urldispatch .py, line 54, in genexpr [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] if preds and not all((p(None, request) for p in preds)): [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] File /home/hong/hm.web/lib/python2.6/site-packages/repoze.bfg-1.3a3-py2.6.egg/repoze/bfg/configurati on.py, line 1680, in header_predicate [Wed May 26 09:12:59 2010] [error] [client 127.0.1.1] return header_val.match(val) is not None Since it is not possible to use pdb with mod_wsgi, I don't know how to further trace and fix the situation. -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ 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
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
