Open to suggestions

Skip to first unread message


May 5, 2009, 1:02:55 PM5/5/09
to web2py Web Framework
Working on another application. One table in the DAL will have about
60 Fields in it. Using one long form would work but gets rather bland.
I would prefer to visually cut it up. I could either capture the data
in multiple screens for input or use a tabbed interface to capture the
data. I am leaning toward the tabbed interface.

The one approach I have considered for a tabbed approach is --


Build the form using helper functions and pass as to dict()

View :

Set up the tabs, display the form and use jQuery hide(), show()
functions using onclick actions to display pieces of the form as

I would be interested if there might be a better technique to consider
to achieve the same ends.



May 5, 2009, 3:22:51 PM5/5/09
to web2py Web Framework
60 fields ! I can't even remember a web app with only half of this.
Sure the data is normalized enough ? Maybe you can think of a multiple
page form.


May 5, 2009, 3:24:54 PM5/5/09
to web2py Web Framework
I would suggest breaking the 60 fields over multiple tables (the way
you want forms to look like) and link them using references.
It will be much easier to handle it long term.



May 5, 2009, 9:23:20 PM5/5/09
to web2py Web Framework
John, I just counted one of my app, an order management system. The
order table has 45 fields. Here is what I did. I put them on the same
page so that all input data are validated together via the comfortable
form.accepts(...). The only downside is the default layout of SQLFORM
(...) for such a big table is long and boring, so I customized the
layout by manually organize a FORM(..) like this:
....//you get the idea
if form.accepts(...): db.orders.insert(**request.vars)

Eventually I got the layout looks great and works, although the
controller's code doesn't look compact.

This must not be the best approach. I plan to refactor it later,
hopefully I can define some Widgets and helpers to shorten the main

Just for your reference.


May 6, 2009, 12:12:52 AM5/6/09
to web2py Web Framework

Normalize, certainly can. If I follow a logical format at best it
might get the count down to 43 fields. I could of course just force
the issue a cut the table up as Massimo suggests and match the fields
with the views to something more manageable. Ultimately it maybe what
I do.


Thanks for the tip. I expected to do something like you suggest to
build the form.

Ted G

May 6, 2009, 1:11:47 AM5/6/09
to web2py Web Framework
I've used the same technique you describe in order to create a better
form layout. In my case I did not have as many fields, but I did have
a few text areas, which created a "vertically challenged" form.

Same as your approach, I create a form using SQLFORM as per normal and
pass it to the view with return dict(form=form).

In the view, the form is defined without using {{=form}}. Instead, the
form and all inputs are declared in the view and grouped into
appropriate divs, which are shown/hidden based on clicking tabs to
view different sections of the form.

Just be sure to include the hidden fields required by form.accepts in
your form. You can do this by including:


within the form as well as

<input type="hidden" name="id" value="{{}}"/>

if the form is being used to update an existing record.

For the inputs in your form, you can use
value="{{=form.record.yourfieldname}}" as the value of the input field
when updating an existing record. Note that form.record does not exist
if your form is creating a new record, therefore you'll need the
appropriate logic in the view to handle setting the appropriate value
for your input fields.

Not sure if the above is the best strategy, but it is one I have been
using with success.



May 6, 2009, 7:58:34 AM5/6/09
to web2py Web Framework
You might want to look at:

It provides an updated alternative to {{=form.record.fieldname}} with
some additional functionality for custom forms including the data
containing "" for add and field label values.

Reply all
Reply to author
0 new messages