* Daniel Kasak <dkasak@xxxxxxxxxxxxxxxxxxxx> [2004-04-27 04:33]:
> A tabular view would also be nice, but would be a 2nd priority for me.
Ah. Well then there isn't any need to throw Gtk2 into the mix.
You're not doing anything graphical, so you shouldn't be using a
widget toolkit in the first place. That would be a crutch by
systems which train the user to do point-n-click programming.
> Create a custom object - lets call it a DBO. A DBO has:
No, let's call it a DBI handle. :-)
> - name
> - DB connection string
> - SQL
> - Primary Key
> - command [ refresh, execute, update, delete ]
Well, it doesn't have SQL, you give it SQL, and that is the way
the "command" bit is offered. That would be pretty much what you
get with DBI.
> So if I created a DBO object and called it 'customers', I would
> then create fields named:
>
> dbo_customers_customer_id
> dbo_customers_first_name
> dbo_customers_last_name
Sounds like designing the database around the GUI.. ugh.
> And the DBO object would loop through each object on the
> window, looking for things which were associated with it by
> name ( ie started with 'dbo_customers' ) and interact with them
> accordingly ( update their values, update the DB with their
> values, delete, etc ).
Here's where you lost me. Do you mean "present input widgets"
when you say "interact"? And what objects are looping over?
> Is this the right way to be going about things?
For what you need, I'd simply slap a few widgets on a dialog,
then connect a few signals to fire off SQL queries as needed.
There's a number of modules on CPAN to make abstracting SQL
queries (aka business logic) away from your frontend easier.
> I realise that the bit where I name objects with dbo_customers
> is a little dodgy, but it would require the least mucking
> around with other things that I don't currently understand.
Database design is something you should at least have a basic
grasp of before you go designing a database application.
Seriously, you'll do yourself a huge favour in the long run if
you take a bit of time to learn about good database design
practices. You don't have to become an expert, but you should
know a few ground rules.
There's probably a good book by Addison-Wesley or some other good
publisher on the subject. (O'Reilly is unlikely to have one on
basics, it would be tied in with some speicific database, if at
all.) Reading the first few chapters should give you a sufficient
overview to start tinkering.
From there, DBI should be straightforward. It's simply an
enormously easy to use interface to throw SQL queries at a
database.
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
|
