[Tutor] Creating and storing objects from a GUI...
Thu, 21 Feb 2002 08:00:52 -0800
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.
What's your opinion on the mixing of XML and RDBMS? Would data stored in a
Database be saved in table/cell format and then extracted to an XML format
through XSLT in order to be displayed elsewhere, or would the database store
the data already in XML? I like the promised flexibility of XML but WOW,
the multitudes of specifications and formats and so on is overwhelming!
Would you in your right mind mingle XML and an RDBMS?
Would I be better off saving the atomized data into the RDBMS and crafting a
number of translation engines for each of the formats I want to display the
Also in response to Remco's (that's a cool name) response, it sounds like a
good idea to try and modularize the project. So that the functions that
process, parse, display, read, write the data are all separate so that when
things change I only have to change the way one process works rather than
redesigning and rerouting every function to point to the new stuff.
I like the idea of keeping things as simple as possible, but the options and
cool choices are terribly, temptingly distracting.
The program I'm working on is for my wife's dance studio. It's a sort of
scheduler/calendar/salary tracker for students and staff. I could probably
buy something that would work right away, but how fun would that be? :)
From: Kirby Urner [mailto:firstname.lastname@example.org]
Sent: 21 February 2002 7:44 AM
To: Israel Evans
Subject: Re: [Tutor] Creating and storing objects from a GUI...
>What choices have you made in situations like these?
How about just a classic RDBMS (relational database)
with field types. Then you've got SQL (way powerful)
and portability (dumping tables to files no problem
-- nothing pickled).
If you want to code using objects, those could be
formed during read-in of specific records, e.g.
screen fields might map to myrecord.firstname and
myrecord.lastname where myrecord is an instance.
That way you could stick validation code in your
parent class as methods e.g. myrecord.updateHomePhone()
would make sure this was a legal phone number etc.
myrecord.write() might update the appropriate table,
having all the right SQL syntax and connectivity
Anyway, that's one idea.
Tutor maillist - Tutor@python.org