View on
Daniel Kasak > Gtk2-Ex-DBI-2.1 > Gtk2::Ex::DBI



Annotate this POD


New  3
Open  0
View/Report Bugs
Module Version: 2.1   Source   Latest Release: Gtk2-Ex-DBI-2.30


Gtk2::Ex::DBI - Bind a Gtk2::GladeXML - generated window to a DBI data source


use DBI; use Gtk2 -init; use Gtk2::GladeXML; use Gtk2::Ex::DBI;

my $dbh = DBI->connect ( "dbi:mysql:dbname=sales;host=screamer;port=3306", "some_username", "salespass", { PrintError => 0, RaiseError => 0, AutoCommit => 1, } );

my $prospects_form = Gtk2::GladeXML->new("/path/to/glade/file/", 'Prospects');

my $data_handler = Gtk2::Ex::DBI->new( { dbh => $dbh, schema => "sales", sql => { select => "*", from => "Prospects", where => "Actve=? and Employees>?", bind_values => [ 1, 200 ], order_by => "ClientName", }, form => $prospects, on_current => \&Prospects_current, calc_fields => { calc_total => 'eval { $self->{form}->get_widget("value_1")->get_text + $self->{form}->get_widget("value_2")->get_text }' }, default_values => { ContractYears => 5, Fee => 2000 } } );

sub Prospects_current {

            # I get called when moving from one record to another ( see on_current key, above )



This module automates the process of tying data from a DBI datasource to widgets on a Glade-generated form. All that is required is that you name your widgets the same as the fields in your data source. You have to set up combo boxes ( ie create your Gtk2::ListStore and attach it to your combo box ) *before* creating your Gtk2::Ex::DBI object.

Steps for use:

* Open a DBI connection

* Create a Gtk2::GladeXML object ( form )

* Create a Gtk2::Ex::DBI object and link it to your form

You would then typically create some buttons and connect them to the methods below to handle common actions such as inserting, moving, deleting, etc.



Object constructor. For more info, see section on CONSTRUCTION below.


Returns a fieldlist as an array, based on the current query. Mainly for internal Gtk2::Ex::DBI use

query ( [ where_object ] )

Requeries the Database Server, either with the current where clause, or with a new one ( if passed ).

Version 2.x expects a where_object hash, containing the following keys:


The where key should contain the where clause, with placeholders ( ? ) for each value. Using placeholders is particularly important if you're assembling a query based on values taken from a form, as users can initiate an SQL injection attack if you insert values directly into your where clause.


bind_values should be an array of values, one for each placeholder in your where clause.

Version 1.x expected to be passed an optional string as a new where clause. This behaviour is still supported for backwards compatibility. If a version 1.x call is detected ( ie if where_object isn't a hash ), any existing bind_values will be deleted


Inserts a new record in the *in-memory* recordset and sets up default values, either from the database schema, or optionally overridden with values from the default_values hash.


Returns the number of records in the current recordset.


Paints the form with current data. Mainly for internal Gtk2::Ex::DBI use.

move ( offset, [ absolute_position ] )

Moves to a specified position in the recordset - either an offset, or an absolute position. If an absolute position is given, the offset is ignored. If there are changes to the current record, these are applied to the Database Server first. Returns TRUE if successful, FALSE if unsuccessful.


Apply changes to the current record back to the Database Server. Returns TRUE if successful, FALSE if unsuccessful.


Sets the 'changed' flag, which is used internally when deciding if an 'apply' is required.


Reverts the current record back to its original state. Deletes the in-memory recordset if we were inserting a new record.


Deletes the current record. Asks for confirmation first. If you are selecting from multiple tables, this method will not work as expected, if at all, as we don't know which table you want to delete from. The best case scenario is an error - this is what MySQL does. Other database may delete from both / all tables. I haven't tried this, but I wouldn't be surprised ...

set_widget_value( fieldname, value )

A convenience function to set a widget ( via it's fieldname ) with a given value. This function will automatically set up data formatting for you ( eg numeric, date ), based on the assumption that you are giving it data in the format that the database server likes ( for example, yyyymmdd format dates ).

get_widget_value( widget_name )

Complimentary to the set_widget_value, this will return the value that data in a current widget REPRESENTS from the database's point of view, ie with formatting stripped. You can call get_widget_value() on non-managed widgets as well as managed ones.

original_value( fieldname )

A convenience function that returns the original value of the given field ( at the current position in the recordset ), since the recordset was last applied. This is also the ONLY way of fetching the value of a field that is IN the recordset, but NOT represented by a widget.

sum_widgets( @widget_names )

Convenience function that returns the sum of all given widgets. get_widget_value() is used to retrieve each value, which will stips formatting from managed widgets, but you can include non-managed widgets as well - they just have to ben in the same Gtk2::GladeXML file.


Locks the current record to prevent editing. For this to succeed, you must have specified a data_lock_field in your constructor. The apply() method is automatically called when locking, and if apply() fails, lock() also fails.


Unlocks a locked record so the user can edit it again.

setup_combo ( widget_name, [ new_where_object ] )

Creates a new model for the combo of widget_name. You can use this to refresh the items in a combo's list. You can optionally pass a hash containing a new where_object ( where clause and bind_values ).

calculator ( Gtk2::Widget )

Opens up a simple calculator dialog that allows the user to enter a list of values to be added. The result will be applied to the given widget ( which assumes a set_text() method ... ie a Gtk2::Entry would be a good choice ).

find_dialog ( [ field ] )

Opens a find 'dialog' ( a window in GTK speak ) that allows the user to query the active table ( whatever's in the sql->{from} clause ). This will allow them to *alter* the where clause. If you only want them to be able to *append* to the existing where clause, then set the disable_full_table_find key to TRUE ( see 'new' method ).

If an optional field is passed, this will be inserted into the dialog as the first field in the criteria list.

Note that the user can currently activate the find_dialog by right-clicking in a text field. To disable this behaviour, set the disable_find key to TRUE ( see 'new' method ).


Returns the current position in the keyset ( starting at zero ).


The new() method expects a hash of key / value pairs.


a DBI database handle


the Gtk2::GladeXML object that created your form


The sql object describes the query to be executed to fetch your records. Note that in contrast to version 1.x, all the keywords ( select, from, where, order by, etc ) are *OMMITTED* ... see above example. This is for consistency and ease of manipulating things. Trust me.

Minimum requirements for the sql object are the 'select' and 'from' keys, or alternatively a 'pass_through'. All others are optional.



The SELECT clause


The FROM clause


The WHERE clause ( try '0=1' for inserting records )


An array of values to bind to placeholders ... you ARE using placeholders, right?


The ORDER BY clause


A command which is passsed directly to the Database Server ( that hopefully returns a recordset ). If a pass_through key is specified, then this will be used as the SQL command, and all the other keys will be ignored. You can use this feature to either construct your own SQL directly, which can include executing a stored procedure that returns a recordset. Recordsets based on a pass_through query will be forced to read_only mode, as updates require that column_info is available. I'm only currently using this feature for executing stored procedures, and column_info doesn't work for these. If you want to enable updates for pass_through queries, you'll have to work on getting column_info working ...

That's it for essential keys. All the rest are optional.


The widgets hash contains information particular to each widget, including formatting information and SQL fieldname to widget name mapping. See the WIDGETS section for more information.


The combos hash describes how to set up GtkComboBoxEntry widgets. See COMBOS section for more informaton.


The PRIMARY KEY of the table you are querying.

As of version 2.0, the primary key is automatically selected for you if you use MySQL. Note, however, that this will only work if the FROM clause contains a single table. If you have a multi-table query, you must specify the primary_key, otherwise the last primary_key encountered will be used. I recommend against using multi-table queries anyway.


A reference to some Perl code to run when moving to a new record


A reference to some Perl code to run *before* applying the current record. Return TRUE to allow the apply method to continue, or FALSE to prevent the apply method from continuing.


A reference to some Perl code to run *after* applying the current record


A reference to some Perl code to run *after* undo() is called. This can either be called by your code directly, or could be called if the user makes changes to a recordset, and then wants to close the form / requery without applying changes, which will call undo()


A reference to some Perl code that runs *every* time the changed signal is fired. Be careful - it's fired a LOT, eg every keypress event in entry widgets, etc


A reference to some Perl code that runs *only* when the record status initially changes for each record ( subsequent changes to the same record won't trigger this code )


A hash of fieldnames / Perl expressions to provide calculated fields


The size of the recordset slice ( in records ) to fetch into memory ONLY change this BEFORE querying


The name of a GtkSpinButton to use as the record spinner. The default is to use a widget called RecordSpiner. However there are a number of reasons why you may want to override this. You can simply pass the name of a widget that *doesn't* exist ( ie NONE ) to disable the use of a record spinner. Otherwise you may want to use a widget with a different name, for example if you have a number of Gtk2::Ex::DBI objects connected to the same Glade XML project.


This is a string you can use to override the default table name ( ie $self->{sql}->{from} ) in GUI error messages.


Disable automatic move() operations when the RecordSpinner is clicked


Whether we allow updates to the recordset ( default = FALSE ; updates allowed )


A HOH of default values to use when a new record is inserted


A flag to silence warnings such as missing widgets


The name of a label to use to indicate the record status. This is especially useful if you have more than 1 Gtk2::Ex::DBI object bound to a single Gtk2::GladeXML object


The schema to query to get field details ( defaults, column types ) ... not required for MySQL


Don't allow the user to replace the where clause; only append to the existing one


Disable the 'find' item in the right-click menu of GtkText widgets ( ie disable user-initiated searches )


The widgets hash contains information particular to each managed widget. Each hash item in the widgets hash should be named after a widget in your Glade XML file. The following are possible keys for each widget:


The sql_fieldname is, as expected the SQL fieldname. This is the name used in selects, updates, deletes and inserts. The most common use ( for me ) is to support SQL aliases. For example, if you have a complex window that has a number of Gtk2::Ex::DBI objects attached to it, you may encounter the situation where you have name clashes. In this case, Gtk2::Ex::DBI will use the sql_fieldname when talking to the database, but will bind to the widget which matches this widget hash's name. Another ( perhaps more natural ) way of generating this behaviour is to simply create an alias in your SQL select string. Gtk2::Ex::DBI parses the select string and populates the sql_fieldname key of the widgets hash where appropriate for you.


This is a HASH of options to control numeric formatting. Possible keys are:


You can specify the number of decimal places values are rounded to when being displayed. Keep in mind that if a user edits data, when they apply, the value displayed in the widget will be the one applied. This default to 2 if you set the 'currency' field.


Whether to fill numbers out to the specified number of decimal places. This is automatically selected if you set the 'currency' field.


Whether to apply currency formatting to data. It adds a dollar sign before values. It also sets the following options if they aren't already specified: - decimal_places - 2 - decimal_fill - TRUE - separate_thousands - TRUE


This is a HASH of options controlling date formatting. Possible options are:


This formatter converts dates from the international standard ( yyyy-mm-dd ) to the Australian ( and maybe others ) fomat ( dd-mm-yyyy ). If you use this formatter, you should also use the complementary output_formatter, also called date_dd-mm-yyyy ... but in the output_formatter array.


This formatter strips off the end of date values. It is useful in cases where the database server returns a DATETIME value and you only want the DATE portion. Keep in mind that when you apply data, you will only be passing a DATE value back to the database.


Gtk2::Ex::DBI uses the GtkComboBoxEntry widget, which is available in gtk 2.4 and above. To populate the list of options, a model ( Gtk2::ListStore ) is attached to the combo. Gtk::Ex::DBI expects this model to have the ID in the 1st column, and the String column 2nd column. You can pack as many other columns in as you like ... at least for now :)

If you choose to set up each combo's model yourself, you *must* do this before constructing your Gtk2::Ex::DBI object.

Alternatively you can pass a hash of combo definitions to the constructor, and they will be set up for you. If you choose this method, you get a couple of other features for free. You will be able to refresh the combo's model with the setup_combo() method ( see above ). Users will also be able to trigger this action by right-clicking in the combo's entry and selecting 'refresh'. You will also get autocompletion set up in the combo's entry widget ( this is triggered after typing the 1st character in the combo's entry ).

To make use of the automated combo setup functionality, create a key in the combos hash, with a name that matches the GtkComboBoxEntry's widget name in your glade xml file. Inside this key, create a hash with the following keys:


An array of field definitions. Each field definition is a hash with the following keys:


The SQL fieldname / expression


The ( Glib ) type of column to create for this field in the Gtk2::ListStore. Possible values are Glib::Int and Glib::String.

cell_data_func ( optional )

A reference to some perl code to use as this columns's renderer's custom cell_data_func. You can use this to perform formatting on the column ( or cell, whatever ) based on the current data. Your function will be passed ( $column, $cell, $model, $iter ), as well as anything else you pass in yourself.


A hash of SQL related stuff. Possible keys are:


The from clause


This can either be a where clause, or a hash with the following keys:


The where key should contain the where clause, with placeholders ( ? ) for each value. Using placeholders is particularly important if you're assembling a query based on values taken from a form, as users can initiate an SQL injection attack if you insert values directly into your where clause.


bind_values should be an array of values, one for each placeholder in your where clause.


An 'order by' clause


A DBI handle to use instead of the current Gtk2::Ex::DBI DBI handle


SQL Server compatibility

To use SQL Server, you should use FreeTDS ==> UnixODBC ==> DBD::ODBC. Only this combination supports the use of bind values in SQL statements, which is a requirement of Gtk2::Ex::DBI. Please make sure you have the *very* *latest* versions of each.

The only problem I've ( recently ) encountered with SQL Server is with the 'money' column type. Avoid using this type, and you should have flawless SQL Server action.


'destroy' method doesn't currently work

I don't know what the problem with this is. I attach a *lot* of signals to widgets. I also go to great lengths to remember them all and disconnect them later. Perhaps I'm missing one of them? Perhaps it's something else. Patches gladly accepted :)


Daniel Kasak -



 - tirelessly offered help and suggestions in response to my endless list of questions

Gtk2-Perl Authors

 - obviously without them, I wouldn't have gotten very far ...

Gtk2-Perl list

 - yet more help, suggestions, and general words of encouragement

Other cool things you should know about: ^

This module is part of an umbrella 'Axis' project, which aims to make Rapid Application Development of database apps using open-source tools a reality. The project includes:

  Gtk2::Ex::DBI                 - forms
  Gtk2::Ex::Datasheet::DBI      - datasheets
  PDF::ReportWriter             - reports

All the above modules are available via cpan, or for more information, screenshots, etc, see:

Crank ON! ^

syntax highlighting: