[Tutor] Creating and storing objects from a GUI...

[Kirby Urner]

At 08:00 AM 2/21/2002 -0800, you wrote:
>I was thinking SQL would be nice, but due to my ignorance, databases,
>still feel a little like a black box to me.  I'll have to do a little
>more research into them.

SQL is a language, I think you realize, not a particular product.
Relational databases have grown up in tandem with this standard
way to pull and put data into 'em.  SQL will also create new tables
from scratch, modify the structure of existing tables, and so on.
If fancy, there's a whole permissions layer, where only some people
get to do some things (such as drop whole tables).  Every RDBMS
from free MySQL through $10K Oracle uses some dialect of SQL, which
is thankfully pretty standard.

XML's tree structures might be the logical result of a query, e.g.
pulling all dancers in Madam X's class might give us:

<class name = "Thursday PM">
<instructor name="Madam X" />
   <student>
     <lastname>Vos Savant</lastname>
     <firstname>Twila</firstname>
   </student>
   <student>
     <lastname>Vos Savant</lastname>
     <firstname>Twila</firstname>
   </student>
</class>

The SQL would look something like:

   SELECT lastname,firstname ;                 # column selection
     FROM students,classes ;                   # two tables
     WHERE students.timeslot = classes.class ; # join condition
     AND classes.class=="Thurs PM" ;           # boolean filter

The XML could then be massaged into formatted output using
XSLT to maybe give the list in table format in the browser (lots
of <td></td> tags and such).

Mediating objects might have done the conversion from returned
records (results of SQL) to XML.

Python could broker the request for this list via a web form,
formulate the SQL and pass it back to whatever RDBMS, and create
the resulting web page on the fly.

But that's all assuming a scenario where your clients are gaining
password-protected access to scheduling info from home, using
Netscape or whatever.  You could add this functionality later
-- if you have a server running Apache or whathaveyou.  But if
this is just a back office app running on a standalone machine,
there's no point blueprinting all this fancy XML->XHTML via XSLT
junk, fun though it may be to play with.

To be super-realistic about the whole thing, if I had a client
breathing down my neck, wanting this calendar/scheduling utility
yesterday, I'd whip it up in Visual FoxPro (presuming they're
Windows).

VFP is vastly superior to VB when it comes to RDBMS type stuff
IMO, has embedded SQL and one of those classic intuitive drag 'n
drop approaches to interface building.  Just slide a button or
grid (rows-n-columns gizmo) onto a form, add some code, and
you're done.  Subclass and customized the canned versions if
you prefer.  Want a calendar object (Gregorian) where you just
click on the day?  There's a canned ActiveX object for that --
just slide it onto a form and bingo bango, you're done.

The thing about Python is, although it's batteries included, if
you want one of those drag-controls-from-a-palette type IDEs for
interface-building, you've gotta pay (unless you can find some
alpha or beta thing).  Hand-crafting a Tk or wx GUI for anything
slightly complicated, even using Pmw widgets (TK widgets on
steroids) is in my opinion rather tedious -- coming as I do,
spoiled as I am, from using the VFP devel environment.

Kirby