Re: [SQLObject] form generation/validation

[Ian B. <ia...@co...>]

Jamie Hillman wrote:
> Hi,
> 
> I was just wondering what kind of state integration with FormEncode
> was in?  I started writing code to generate forms from (and validate
> forms against) SQLObject schemas myself, then I realised it was a
> future goal for SQLObject.  From reading the FormEncode docs it seems
> that it will read form specifications from schemas but it doesn't
> mention SQLObject schemas.  Is there any useable code out there?

Eh... at the moment FormEncode is kind of broken, and there were just 
too many issues to try to deal with all of them at once.  It was just 
too fragile, so I'm trying to simplify it.

Ultimately, the problem is hard -- I really want to be able to edit a 
set of objects at once, not just a single object, so that UI isn't 
unnecessarily tied to the way the backend objects are factored. 
FormEncode has all the basic features to do this, and I'd started 
playing around with ways of defining graphs of objects, so you could 
deal with complex subobjects.  E.g., one attribute might be immutable, 
so if you change it you'd actually remove the attribute (maybe deleting 
it from the database) and add a new one.  Or, another attribute is a 
list of objects, each of which has its own behavior.  Or another 
attribute contains an object that can be edited in place.  Even fairly 
simple systems of objects can be fairly complex from that perspective. 
But maybe trying to define the controller declaratively in this way was 
too ambitious.

> The were two problems in generating/validating forms with my
> implementation that I might as well mention whilst i'm here, to see
> what you think.  The first problem was ordering - i'd like to keep
> the generated form fields in the same order as they appear in the
> schema.  This _columns dictionary didn't preserve this order and from
> looking at the code it would seem that this is unavoidable?  I ended
> up creating a separate list of COL objects which preserved the order
> and using that to generate forms.

In FormEncode the order of fields is preserved.  In that case everytime 
a class is instantiated we increment a global counter, and if you sort 
based on that counter you get the order of the objects.  Since in 
FormEncode you can also use classes in place of objects, there's a 
metaclass that adds the counter to classes as well (though that leads to 
a certain amount of confusion).  Anyway, it's implemented in declarative.py

> The second "problem" was generating a readable name for fields in
> forms (I generate a table with prompts next to each field), which I
> just did by adding a property to the columns - prettyName.
> 
> So far i'm generating forms well enough, and i'm just about to start
> validation code.

I've separated out the validation code from FormEncode, just this Friday 
or so.  It's in svn://colorstudy.com/trunk/Validator -- it's the part of 
FormEncode that has been the most stable, and where I don't expect any 
changes (well, I actually started making some API changes when I moved 
it out, but anyway...).  It still uses PyProtocols, but I might take 
that out; it's just been too confusing to deal with all the different 
mechanisms, and PyProtocols is a more subtle mechanism than most.

Like Carlos said, it gets rather confusing when you consider all the 
paths data can take.  I think it's better to start out very explicit, 
and then build up abstractions, so I'm trying to pull back to something 
more explicit.

Validator still uses DataTest (svn://colorstudy.com/trunk/DataTest), but 
I plan to move it to py.test (http://codespeak.net/py/current/doc/test.html)

> So I guess the point of my long rambling email is to see if any of
> this has been done already and if I can get hold of that code, and if
> not if I can help out by making my code fit your goals.
> 
> Thanks for your work on SQLObject,

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org