On Wed, Apr 28, 2004 at 09:23:22 +1000, Daniel Kasak wrote:
Now seriously. A better way of handling DB updates is needed for large-scale projects. You can't expect people to hand-code the updates for every single field on every single window. I'm proposing an alternative that will same time, and ( God forbid ) encourage more people to use Perl & GTK in a corporate environment. Unfortunately for me, I simply don't understand enough about OO programming to complete the above ideas without spending considerable time, so I'm after *constructive* comments ( ie hold off on the 'lazy point-and-click' crap please ) to point me in the right direction so I don't waste my time. Any takers?
Well, you'll most probably have to do most coding, as you are the one who need it. However, it should not be that hard. But I can give you some basic hints. If I understood your previous mails correctly, you want to have a dialog showing a single record in the database (which may be record from a view or somesuch, of course) and allowing the user to update it, add new or delete it alogether. Plus some way of telling it which record it should show. Now doing some fancy layout automaticaly would be pretty hard (if not impossible). But a simple two-column GtkTable with names of fileds in the left column and GtkEntries (or other widgets where appropriate) for values in the right is both doable and sufficient. So: - You'll need a bunch of generic routines to set up appropriate widgets for various data types that appear in the database. These will - Create appropriate widgets (GtkEntry for text, GtkEntry or GtkSpinButton for numbers etc.) - Set up relevant signals, passing some "handle" object as the data. You could do without OO alltogether, but OO in perl is really, really simple. They will be called to add lines to the dialog. You should get the order and types by parsing the table schema. - You will need an object for the whole dialog, that will tie the things together. All the signals should get it as the user data. It actualy don't need to be blessed. Just a reference where you can put the database data will do. - You will need an object representing the record. Again, it don't need to be blessed -- the arrayref or hashref given by DBI should do. Just you need to be able to replace it in the dialog object (to swithc to another record) and you need to be able to construct update query from it. - You will need functions (that may, but need not, be called as methods), that will do the database operations. - There is the updating operation. It should gather the keys from your object and issue appropriate update statement. - There is fetching next/previous record from a list. - You'll need to have some query results connected with the controling object. - There is searching. - For the first step, you can do very simple query with this interface -- fill in some fields, leave the rest blank and request all records, that match the filled fields. You will need a table to get OR. - You may want to allow giving SQL commands (depends on skills of future users). - You will need some buttons to fire the actions. You should make them sensitive/insensitive depending on what is currently possible (ie. only allow next/previous record if there are some records etc.). - The generic routines should not be too hard. Most of them will probably create GtkEntry. Just bind the relevant signal to a handler, that will modify relevant field in the structure representing record. For each entry type, there would be one signal handler, that would be passed which field it operates on. - You should check syntactic correctness of the entered values here. You may also run integrity-checks. These should of course be one routine for each table, run on any change. (In PosgreSQL I'd just have a transaction open, update right away and let the database do the checking -- and only commit when user clicks "Update". I don't think MySQL has integrity checks, but you can do them in perl). - Generating the SQL update commands shouldn't be hard either. You just need to remember which table is the data from, the record ID and which fields have changed. - Now making that to a list (GtkTreeView + custom GtkTreeModel), each line being a record won't be too hard either. You should be even able to do away with just Gtk2::SimpleList! When you do the select, you get (using selectall_arrayref) a list-of-lists. Just assign it to the SimpleList with appropriately set columns (again, columns should be set up from parsed table schema). You can either use editable cell renderers, or copy the values to a dialog described above on selection change (easier). Well, I know it looks like a lot of work. But it's not THAT hard. Feel free to ask for details, where you can't make sense of the docs. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb ucw cz>
Description: Digital signature