Thread: [SQLObject] autogenerate formencode validation schemas from sqlobjects
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Jamie W. <ja...@sp...> - 2005-09-16 05:01:13
|
Is there a way to generate formencode schemas from SQLObject classes? I've just been reading Ben Bangert's notes on form validation with myghty, and it seems a real waste and a potential for error to have to define the schema twice -- the SQLObject definition (or in the database itself, and using =66romDatabase) and again in for formencode's benefit. |
From: Kevin D. <da...@gm...> - 2005-09-16 11:34:18
|
I would think it's possible, but I'd have to play with it to know how useful in practice it can be. The UI for some types of things looks different from what winds up in the database. You could certainly look through the columns and do the following: - for columns without a default, make sure there's a value - for strings, check the length - for numbers, make sure it's an appropriate number It might be worth the experiment sometime... Kevin On 9/16/05, Jamie Wilkinson <ja...@sp...> wrote: > Is there a way to generate formencode schemas from SQLObject classes? I'= ve > just been reading Ben Bangert's notes on form validation with myghty, and= it > seems a real waste and a potential for error to have to define the schema > twice -- the SQLObject definition (or in the database itself, and using > fromDatabase) and again in for formencode's benefit. |
From: Jamie W. <ja...@sp...> - 2005-09-16 14:06:32
|
This one time, at band camp, Kevin Dangoor wrote: >I would think it's possible, but I'd have to play with it to know how >useful in practice it can be. The UI for some types of things looks >different from what winds up in the database. > >You could certainly look through the columns and do the following: >- for columns without a default, make sure there's a value >- for strings, check the length >- for numbers, make sure it's an appropriate number > >It might be worth the experiment sometime... Well, if it doesn't exist, then I'd want to write it for my own projects, because that sounds far more interesting than having two copies of a schema :) The only thing preventing me doing so already is a lack of understanding of python internals. How does one look at the column declarations, given a class or instance of some SQLObject child? |
From: Oleg B. <ph...@ma...> - 2005-09-16 14:30:08
|
On Sat, Sep 17, 2005 at 12:06:49AM +1000, Jamie Wilkinson wrote: > How does one look at the column declarations, given a class or > instance of some SQLObject child? print dir(cls.sqlmeta) print cls.sqlmeta.columns print cls.sqlmeta.columnDefinitions etc... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Luke O. <lu...@me...> - 2005-09-16 15:17:11
|
I started down this path, didn't get far but more for indecision on interface than impossibility - it seemed quite doable: 1. Generating default schema entries for fields, somewhat. With a handful of custom validators/schemas to represent how you want to treat foreignKeys, joins, etc, better. How best to allow per-application mapping of these default entries to column types is still undecided for me. Also, how to handle overriding vs extending these defaults on a per-schema basis. 2. Without HTML generation of schemas (used to be htmlview? been a little while since I've been in the FE code), you still end up maintaining parallel structures. 2 (SO/FE schema and UI) instead of 3 is something of an improvement, but still a big demotivator for me. I think I understand why htmlview got pulled (again, the question of what's a simple intuitive way to define default mappings from schema to UI elements, and allow you to override just those you want), but for many things I still cling to FFK's emphasis on HTML generation. 3. Big benefit in my mind would be in automatically handling converting SO values to FE defaults, and storing the validated values back into the SO object (or creating a new one, etc). This is a little more framework stuff than just SO->Schema conversion, but definitely part of the motivation. 4. For me, this would also need to read/write my _get_/_set_ 'columns', not just the database columns. Probably can't get any automatic default validation on these, so they'd have to be explicitly defined in the FE schema. - Luke Quoting Kevin Dangoor <da...@gm...>: > I would think it's possible, but I'd have to play with it to know how > useful in practice it can be. The UI for some types of things looks > different from what winds up in the database. > > You could certainly look through the columns and do the following: > - for columns without a default, make sure there's a value > - for strings, check the length > - for numbers, make sure it's an appropriate number > > It might be worth the experiment sometime... > > Kevin > > On 9/16/05, Jamie Wilkinson <ja...@sp...> wrote: >> Is there a way to generate formencode schemas from SQLObject classes? I've >> just been reading Ben Bangert's notes on form validation with myghty, and it >> seems a real waste and a potential for error to have to define the schema >> twice -- the SQLObject definition (or in the database itself, and using >> fromDatabase) and again in for formencode's benefit. -- The Pursuit of Counterfactual Histories |
From: Ian B. <ia...@co...> - 2005-09-16 15:27:20
|
Jamie Wilkinson wrote: > Is there a way to generate formencode schemas from SQLObject classes? I've > just been reading Ben Bangert's notes on form validation with myghty, and it > seems a real waste and a potential for error to have to define the schema > twice -- the SQLObject definition (or in the database itself, and using > fromDatabase) and again in for formencode's benefit. There actually is a routine that Peter Hunt submitted but I didn't commit. It had some logic that just didn't make any sense outside of the context of Subway. Probably in a simplified form it could go into sqlmeta. (SQLObject 0.6.1 doesn't use FormEncode validators, so this is only at all possible with 0.7) def getMatchingColumnNames(sqlmeta, fields=[], tags=[]): """ Return column names that are in fields and match tags. Maintains ordering specified in the parameters. """ # we have to do this in a sub-optimal way to # ensure the ordering of the fields and tags if not fields and not tags: fields = sqlmeta.columns.keys() # next, loop through the sqlobject looking for tags for tag in tags: for name in filter(lambda k: k not in fields, sqlmeta.columns.keys()): socol = sqlmeta.columns[name] if tag in socol.tags: fields.append(name) return fields getMatchingColumnNames = classmethod(getMatchingColumnNames) def getSchema(sqlmeta, fields=[], tags=[]): s = schema.Schema() fields = sqlmeta.getMatchingColumnNames(fields, tags) for name in fields: socol = sqlmeta.columns[name] if socol.validator: s.add_field(name, socol.validator) else: s.add_field(name, compound.All()) return s getSchema = classmethod(getSchema) -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |