Johannes Erdfelt
johannes at erdfelt.com
Tue Oct 19 19:53:36 EDT 2004
On Tue, Oct 19, 2004, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > On Oct 19 14:11, Johannes Erdfelt <johannes at erdfelt.com> wrote: > > > > Subject: [mod_python] vampire form validation > > > > The list is built using objects, allowing for extensibility, and is > > passed to the application as a class object with the members > > automatically created from the name of the variable. > > > > Something like this (I'm in the middle of porting and making some > > changes to existing code, so this is a rough draft): > > > > from vampire import form > > > > __form_vars__ = [ > > form.integer("userid", required = 0), > > form.submit("submit", [ > > form.string("name", required = 1), # 1 could be the default > > form.string("address"), > > form.string("city"), > > form.string("state"), > > form.string("country", default = "US"), > > ]), > > ] > > Would the fact that methods are named based on type be limiting? In > order to be more generic, might you have a single method to register > fields and use type objects instead. > > form.define("address",types.StringType) > form.define("count",types.IntType) > > I guess it still means that internally you have to enumerate out some > methods which do the conversions for the differing types, but if one > had a registration mechanism of some form, it might open up the > possibility where you could define your own custom type objects and > register special decoders for that type to have input automatically > converted into an instance of a special class object you have written > rather than just basic types and lists. I figure this can all be done via classes. The implementation I've done has a base class, and then all of the type clases derived. If one wanted to make a phone number validator, they could extend the form.string class to do some extra validation to ensure the type is a string and it's a well formed phone number. Although I don't know how useful that will be. All of the cases I've thought of have complex interdependencies that might not be easy to implement (phone number formats vary from country to country so to ensure it's valid, it would need to know the country, etc...) Atleast it's possible to be done :) > > The handler would then expect a variable called 'form', which could be > > used like this: > > > > req.write("you requested we create a user with this address:\n") > > req.write(" %s\n" % form.name) > > req.write(" %s\n" % form.address) > > req.write(" %s, %s\n" % (form.city, form.state)) > > req.write(" %s\n" % form.state) > > In mod_python.publisher the util.FieldStorage instance is stuffed into > the req object as req.form. It might be better to do something similar > and stuff it in the req object rather than introduce another special name > that then can't be used as a form field name. That's a good point. It's not necessary and should probably be left in the req object like it currently is. > I certainly think something to assist in form validation would be a good > thing and I am sure it is something a few people have probably tackled > before. Thus will be interested to here how other people have approached > it as well. Amongst all the different variants, we can come up with a > nice general approach that suits a lot of needs. Yes, that was what I was hoping for while I ported and modified my implementation. When I get mine done, I'll post a patch for comments. JE
|