sqlobject-discuss

[SQLObject] form generation/validation

[Jamie H. <ma...@ja...>]

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?

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.

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.

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,

Jamie Hillman

Re: [SQLObject] form generation/validation

[Carlos R. <car...@gm...>]

On Mon, 25 Oct 2004 10:51:21 +0100, Jamie Hillman
<ma...@ja...> wrote:
000000000000000000000000000000000000000000000000000000000000
> 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.

Hi Jamie,

I've had a conversation a few days ago with Ian regarding FormEncode
and generic 'declarative' issues. I've written a order-preserving
metaclass to solve another problem, but I think that the same approach
could be used in SQLObject. Python doesn't give low-level support for
ordering; dicts don't store ordering information, and classes uses
normal dicts to store members as they are created. To solve this
problem, you need to order the columns yourself. The basic idea is
that the column attributes can be numbered as they are created, using
a simple counter (derived from itertools.count(), in my case). This
number is an internal attribute of the column and can be used to sort
them.

** Another approach was suggested a c.l.py a few days ago, that is
generic and doesn't required the attributes to store any information;
it involves checking the stack frame and the co_names member of the
function code block (which lists the locals in the order that they
were declared), but that's not needed for SQLObject as all interesting
objects are already classes that can implementing the ordering
behavior themselves.

> 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.

My personal conclusion after talking to Ian on this is that it's
difficult to mix several 'aspects' of the fields into a single
representation. In other words, as you add functionality to SQLObject,
the structure starts to become confusing and less manageable. For
example: the ordering isn't always the same for all operations (table
definition, form definition, and validation); the same table can be
viewed in several diffferent ways (more than one form); validation
rules may change upon context.

I don't have a solution for this problem (yet :-)), but I think that
it's better to keep each part of the problem into their own object,
and make all objects aware of each other and able to play together. In
this scenario, SQLObject takes care of the data definition and
persistence; FormEncode (or another similar solution) takes care of
form definition; a validation object stores the validation rules, and
can be passed to the form definition. It's not the end of it --
reports, advanced lookup lists, and other types of objects can be also
implemented.

Of course, that's *my own understanding of the problem*, and by no
means it's the only possible solution. I'm working on it, but my code
is still pretty much experimental, and still subject to huge changes,
but I would love to discuss it.
 


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

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

Re: [SQLObject] form generation/validation

[Carlos R. <car...@gm...>]

On Mon, 25 Oct 2004 17:24:37 +0100, Jamie Hillman
<ma...@ja...> wrote:
> It would be nice if SQLObject did preserve ordering as it would 
> make form-generation hacks like mine a bit easier :-)

I've sent a copy of this reply to the list; I think it's relevant, and
I hope you don't mind.

Not only form generation, but any declarative style add-on would be
easier to integrate. Examples are reports and views. Also, tables
created by SQLObject would have its columns correctly ordered in the
database, which is a small plus. Its somewhat strange to check the
database using another tool and see the columns in arbitrary order.
Not a big deal, but strange nonetheless.

> Yeah I see what you're saying here but when implementing something 
> simple, as I am, it seems wasted effort to generate two schemas (one
> for forms, one for the database).  Though you could still use the one
> schema and have different objects "decorating" the information for 
> different purposes.

The problem is that applications tend to stay simple for a very short
period of time :-) My own idea is similar to a 'decorator'. I'm now
studying aspects, and aspect oriented programming, in my plentiful
spare time (of course, this is a joke -- the spare time, that is). 
For what I have read, AOP tools (such as JAspect) already solve some
of the complex theorethical issues, including the development of
advanced graph representations for what they call 'cross-cutting
concerns' -- aspects that affect the software in orthogonal ways, and
that support really complex combinations of code. So I don't have
really a way to foresee when will I be able to push again on real
development. My current model is confusing and I don't intend to push
it beyond it's limits .

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...