durusmail: quixote-users: pyPgSQL/Quixote data cursor browse form
pyPgSQL/Quixote data cursor browse form
2003-04-27
2003-04-27
pyPgSQL/Quixote data cursor browse form
Benjamin Scherrey
2003-04-27
        Here is my first cut at a usable data table browser implemented as a
Quixote form (hack).
Not being too intimate with the guts of pyPgSQL or Quixote, I find it works
pretty well and doesn't
have too many nasty surprises. I'd be VERY curious as to comments or
recommendations on how
to accomplish the same functionality in a more correct or elegant manner.

        All that's needed to try the thing out is to instantiate an instance of
DataTableForm,
passing it a cursor that has executed its SQL statement. This will provide you
with a page of 'X'
rows (optional __init__ parm defaults to 10) of your data with an additional
header row listing each
field name. The data is strictly read-only although the fields appear to be
editable - no changes will
make it to the database (doesn't HTML allow you to specifiy an "input" as non-
editable?).

        The other neat hack that I implemented is the ability to optionally
filter your data. If you
also pass in the select statement text (with the where clause eliminated and any
where predicates
in a seperate string if needed), under each column header will be a blank input
field (our form's
actual text widgets) and a new "Filter" button to the left of the table which,
when pressed, will take
the contents of the entry widgets and apply them as a new where clause (which
will get stuck
between the select string and the predicate string which is why I make you
seperate them) against
your cursor. This trick is a bit too invasive for my taste and I'm thinking of
passing the filtering tuples
into a callback function (so the form can be completely ignorant of the SQL)
that handles the
database but haven't decided the best way to do this. I found it interesting (ok
- a bit frustrating)
when implementing this, that, if you manually generate a submit button in your
html output, but there
is not a matching submit_button_widget instance in your form with the same name
- selecting it will
reload the form but your action method will never be called. As a result, you'll
see the "Filter" submit
present twice on the form... One thing I'd like to do is put an Edit or Select
submit_button to the left
of each row of data and have it do something useful but I don't want to use
javascript (if I can
avoid it) and don't want to add a button for each row along the bottom as I have
for Filter.

        My first pass at this had me reimplementing several of the Form methods
but I finally
figured out enough about how the form works to cut this way back to just
__render_visible_widgets() and a few supporting methods so that I don't groan
too much when
considering the structure. I get the feeling I probably could have handled the
table content field
generation a little cleaner but my attempts always hit a snag so I just took
complete control over it.

        So has anyone else tried to implement something like this within
Quixote? Does my
implementation show a complete ignorance of the framework's purpose or is this
pretty much how
it's done?

        One last thing I noticed is that pyPgSQL reports a size of 4 for integer
types which is
really bad because this means I can't enter in a filter of greater than 4
characters for integer fields.
This comes from the cursor.decription of the select results. Anyone recommend a
good way to deal
with this? Is it a pyPgSQL anomoly or is the 4 supposed to be interpreted
differently for integers?

        many thanx,

                Ben Scherrey

reply