Re: high level application frameworkl

Dirk Koopman wrote:

For many years (about 26) I have used an "application framework" of my
own devising (in various incarnations) for separating "business
logic" [ugh] and data manipulation, completely, from visual
representation on "curses" based terminals. 

It allows programmers to say things like: take these data fields

Gtk2::Ex::DBI ... links to ...

display them according to form xxx;


 then tell me if these values are
entered or those keys are pressed;

Either connect to the 'changed' signal of each widget and do things
while the user is inputting data, or pull all the values at once when
the data entry is complete and the user hits 'apply'. With Gtk2::Ex::DBI
you can do all this by defining a 'before_apply' callback which is run
before the record is applied.

I may change the contents of some
fields and redisplay others. Automatically go from field to field in an
obvious pattern (up/down, mouse click)

gtk+'s default widget focus ordering is very good. Otherwise you can
override it by connecting to the focus_out_event signal and forcing the
focus somewhere else.

unless I fiddle about during the
course of execution of the form.

The point of this is to allow the development of any "prettiness" of
form to be completely (and I do not exaggerate) detached from the
development of the workings of the program. The program is concerned
*only* with dealing with the logic and data, together with starting the
correct form to do any operator interaction. It does not care (nor know)
what the screen looks like.

This is why people like Glade. I'm not sure why you don't like it. I
find it invaluable. The alternative is a LOT more typing and clicking
and carrying on for the same effect. And lets not talk about what
happens when you want to make major modifications to your GUI ...

Fancy GUI widget drawing programs are not required.

Is there such a thing out there for Gtk-Perl or do I have to go and
write (another) one?

There are bits and pieces. If you give more detailed examples maybe
someone will be able to point you to something. I'm still not certain
what you're after.

For the absence of any doubt at all: glade is exactly *not* what I want
or require. To do anything real seems to require far too much writing
and clicking.


I am looking for something that is the next level up, that imposes a
discipline (and programming paradigm) on the programmer whilst allowing
flexibility (on the part of someone else) to make it all look pretty. 

So for instance: the need to process the field called 'accno' in a form
called 'show_accounts' might call back on function called 'accno' in a
perl package called 'show_accounts' (or some defined munging of those
names) and it would know to do this because the package exists and the
function is defined therein. I.e. all deeply automagical.

Make a Glade XML file to describe the GUI. Seriously. Then make a
package to manage the form, create the GUI from the Glade XML file, and
contain all the app logic for that particular form. Then from your main
app, every time you want one of these forms, go:

$globals->{form}->{some_form} = forms::some_form->new( $globals );

Potentially we are talking 10's or 100's of different forms or screens
here for large scale business systems. 
Well I've got probably 100 forms all up, spread across 5 different
internal applications. It's remarkably managable.

Anyway, have a look at my projects at ... there are 3 projects, for
'forms', 'datasheets', and 'reports'. If you're dealing with a database,
then it's strongly recommended :) The forms module is the only one that
requires the use of Glade.

Also of possible interest is Gtk2::Ex::FormFactory ...
I haven't used it ( I prefer Glade ), so I can't tell you a whole lot
about it, but it might be what you're looking for in automating form setup.

Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: dkasak nusconsulting com au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]