Thanks, Mike. I think you are right. Tracking back through the inheritance chain in Formencode I see that formencode.Schema is ultimately derived from formencode.declarative.Declarative (a pretty broad hint, if you ask me). Declarative does a lot of gymnastics to make Schema classes callable, and to generally make them, well, declarative.
I'm coming around to seeing the value in doing things declaratively now. And besides, trying to do the in-place modification things I was doing is clearly contrary to Formencode's design intent. Doug On Dec 15, 12:09 am, Mike Burrows <[email protected]> wrote: > Hi Doug, > > I'm not 100% certain, but I strongly suspect that you're modifying a > class attribute. What I do looks more like this: > > class SaveSchema(formencode.Schema): > # common > bar = ... > baz = ... > # initially optional > foo = formencode.validators.Set(if_missing=[]) > > class SubmitSchema(SaveSchema): > # mandatory for Submit > foo = formencode.validators.Set(required=True) > > If you don't like having one inherit from the other you could pull out > a common base schema for your form. Taking that thought a little > further, my form schemas don't inherit from formencode.Schema directly > but from a BaseSchema defined in lib.base that keeps app-wide defaults > in one place. > > I have built on the above structure to customise schemas for things > like csv imports whose validation requirements differed from those of > the form. There's a something a bit nicer about doing things > declaratively (and avoiding in-place modification) and here it's good > that it documents clearly which validations are general and which are > special to which context. > > Hope that helps, > Mike > [email protected]http://positiveincline.comhttp://twitter.com/asplake > > On Dec 14, 9:37 pm, Doug Latornell <[email protected]> wrote: > > > > > > > > > I have a Formencode schema that I use when the user saves data from a > > form as an interim step in their workflow. I'm trying to use a > > subclass of that schema with modified field attributes for the step > > when the user if finished their work. Here's a toy example: > > > >>> import formencode > > > >>> class SaveSchema(formencode.Schema): > > > ... foo = formencode.validators.Set(if_missing=[]) > > ...>>> class SubmitSchema(SaveSchema): > > > ... def modify_schema(self): > > ... self.fields['foo'].if_missing = formencode.NoDefault > > ... > > > The idea of this is that the user can save without having made a > > selection for foo, but if they try to submit without having done so a > > formencode.Invalid with be raised. > > > This arrangement appears to work in my app, but I'm seeing some > > weirdness in my tests that I can reproduce from this toy example: > > > >>> schema = SchemaSave() > > >>> assert schema.fields['foo'].if_missing == [] > > > >>> schema = SchemaSubmit() > > >>> schema.modify_schema() > > >>> assert schema.fields['foo'].if_missing == formencode.NoDefault > > > >>> schema = SchemaSave() > > >>> assert schema.fields['foo'].if_missing == [] > > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > AssertionError > > > >>> assert schema.fields['foo'].if_missing == formencode.NoDefault > > > It appears that the 2nd instance of SaveSchema() is not, in fact, a > > new instance. It carries the result of modify_schema(). > > > Am I doing something horribly wrong by trying to modify a schema like > > this? > > > Doug -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
