[DB-SIG] Re: [Python-Dev] database APIs
Luke Kenneth Casson Leighton
lkcl@samba-tng.org
Wed, 5 Feb 2003 21:45:51 +0000
On Wed, Feb 05, 2003 at 01:04:11PM -0500, Kevin Jacobs wrote:
> > okay, so... the classes HC, TC and IC specify formatting,
> > and are applied to each of the data rows?
>
> They are applied to each cell, and can perform arbitrary functions like
> adding CSS classes, converting to localized formats, etc.
ack!
> > step 1, get data:
> > ----------------
> >
> > i went for a less object-orientated approach (no table class)
> > and i also combined the header and database field names into
> > tuples.
> >
> > the reason for this is simply that i find generating new reports
> > to be much simpler: cut/paste one line from one report to the
> > next and you get the database field, heading name and display
> > function all at once.
>
> Many of our reports require formatting, rollups, data dependent logic, URL
> embedding, etc.
url embedding i do as a value-specific formatting function.
if the function has three arguments the _entire_ dictionary
(of cur.fetchone()) is passed to it as arg1; the field name as arg2;
and for good luck str(thevalue) i don't know why i did this arg3!
there is _one_ instance where i had to do something weird:
transposition of an entire table.
that _was_ a pain and i created a class with a fetchone()
function on it.
it was for VAT pricing / totals.
the two lists were Quantity and Cost.
> > the approach above that you have taken you would need to
> > cut/paste in three or more separate places, running the risk
> > of not putting the right header name with the field.
>
> The table renderer makes sure that your formats match your data, so it is
> easy to detect problems like that.
hmmmm :) easy to detect problem. hmmm.
easier to avoid problem in first place, neh?
:)
> In practice, we have hundreds of reports
> and never have a problem with keeping track of fields.
once written,
> We also have reports
> that have very complex multi-line headers with spans and text labels that do
> not match 1:1 with the data. We also have reports that have many different
> row formats intermixed within them.
yeh, it hadn't occurred to me that anyone would want to use
radically different row formats.
i _did_ put in some code that would allow me to format the ENTIRE
<td /> entry thereby making it possible to set the colspan, etc.
i guess... *thinks*...
if i split display_table() down into its basic components...
>
> > step 2, display data:
> > --------------------
> >
> > this is where i lose some of the flexibility that you have,
> > in creating tables. i have to say that i _did_ consider doing
> > classes (like you have already) but i wanted to strip out
> > ALL evidence of HTML from the application so that it becomeso
> > possible to do GUI and curses stuff.
>
> You didn't see any HTML in our version, did you?
true .... except in the name :)
> We have a wxWindows and
> ReportLab renderers that work very well. The only tricky part was
> imlementing our own engine to apply CSS stylesheets for each backend.
oo, sounds really good!
> > The Plan is to place in a template (xml, sql, object, whatever):
> >
> > - a list of the field names etc.
> > - a list of the optional function names
> > (or is it reasonable to instead have a class which is
> > expected to have display_fieldname_in_html()?
> > - the descriptive heading.
> > - specifications on what to do with the data, how to display it.
> >
> > clearly if you want to do GTK or other GUI applications you use a
> > different template, it specifies do-other-base-class-to-display,
> > etc.
>
> Again, this presupposes that you have:
>
> 1) Tables with a single, simple header row
ah, not necessarily... double-checking...
yep, you're right: the custom/html.py display_table_header()
function does a single header row - not necessarily simple,
but definitely single.
> 2) All rows are formatted homogeneously
again, like i said: the formatting function could output
a <td colspan="N">, i do have that possibility covered.
> 3) No rollups, subtotals, or any other forms of aggregation or delimiters.
> 4) No non-trivially data-dependent formats
that _can_ be covered by:
- pre-processing the data and returning an alternative object
on which fetchone() can be called to return its data row by row.
- passing in a different display_row_fn
- doing a separate table for each different data set, with
row-headers switched off.
one thing i haven't mentioned is that quite often i do a row
where the value display function does yet another database query,
so the <td /> entry is actually another table (yes i _do_ know
how long netscape / mozilla takes to display tables-in-tables).
or an <option selected="" /> set on a per-row basis.
etc.
> ;)
> I'm not trying to change your mind, but our clients need all of the above
> (and more!).
i understand: i'm trying to get you to convince me to
chuck some demand-driven code where the original demands
weren't so demanding [as your clients]
... i know what's bothering me.
the number of lines of code to do reports.
the less lines the better, esp. with 16 report generation
functions for stock control; 10 report functions in the
product selection page.
so -
help me out here: save me some work.
i'll send you a patch to SQLobject to do INSERT ... SELECT :)
l.
--
----------------------------------------------------------
this message is private, confidential, and is intented for
the specified recipients only. if you received in error,
altered, deleted, modified, destroyed or interfered with
the contents of this message, in whole or in part, please
inform the sender (that's me), immediately.
if you, the recipient, reply to this message, and do not
then receive a response, please consider your reply to have
been lost or deliberately destroyed: i *always* acknowledge
personal email received. please therefore take appropriate
action and use appropriate protocols to ensure effective
communication.
thank you.