[wxPython-users] Grid Cell Renderer

[Mark Erbaugh]

On Wed, 2008-01-02 at 15:11 -0800, Rich Shepard wrote:
>    I must be missing something because I don't see any problem. For
> example, you have a combo box with CATEGORY names displayed. When your
> user selects a name, your SELECT statement would match the MATERIAL
> foreign key to the CATAGORY primary key (using your dictionary) and
> display the appropriate MATERIAL string. Is this not what you want?
> And, each row in the grid has a different CATEGORY?

That's not quite what I had in mind.

Here are a few sample CATEGORY records:

rsn | Name
001 | Steel
002 | Aluminum
003 | Electical

And some matching MATERIAL records:

rsn | cat | Name
001 | 001 | 4' by 8' by 0.25"
002 | 001 | 4' by 10' by 0.25"
003 | 002 | 4' by 8' by 0.25"
004 | 002 | 4' by 10' by 0.25"
005 | 003 | 20A panel
006 | 004 | duplex outlet


The grid in question will show all MATERIAL records (there will be only
a couple hundred). They will be retrieved from the database with a
single query: 'select rsn, cat, Name from MATERIAL'

However, instead of displaying the integer values for the category
column, I want to display the name 

rsn | category   | Name
001 | Steel      | 4' by 8' by 0.25"
002 | Steel      | 4' by 10' by 0.25"
003 | Aluminum   | 4' by 8' by 0.25"
004 | Aluminum   | 4' by 10' by 0.25"
005 | Electrical | 20A panel
006 | Electrical | duplex outlet

When the user edits the category column, they do so by a drop down list.

An alternative would be to select the rows with a join to get category
names:  select m.rsn, c.name, m.name from MATERIAL m join CATEGORY c
on ...

Then use just user the drop down list to force the user to select a
valid category and then translate from the category string to it's RSN
in the process that writes the rows to the database.

>    IIRC, wxPython implements the MVC concept imperfectly. And, there
> are valid situations when de-normalizing relational database tables is
> also justified for speed and ease of use. What works ought to be the
> determining criterion.

I agree.  After composing this reply, I'm considering storing the
category string directly in the MATERIAL table.  In this application,
the only advantage of normalizing the category name is to allow the
category name to change and that's unlikely enough that it could be
handled with a mass update: update material set c_name=<NEW CATEGORY>
where c_name = <OLD CATEGORY>

Mark