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