Re: Application framework

Ok, before you read all this remember - it easy to critise :) - some of this is probably worth ignoring ... Gtk / naming generally: ------------------------------- for the pear classes , I would stick with GTK_Application, GTK_Dialog_Login, GTK_Dialog having said that, at present (if and when GTK2/ZE2) becomes a reality, BC will be totally blown apart for GTK apps - as $this->okButton =& new GtkButton("OK"); would become $this->okButton = new GtkButton("OK"); (no aliasing, as objects dont get copied using '=' any more.. - So I would be tempted to start a tree GTK1_* Application: ---------------- Its very difficult to write a generic Application framework, I would create a name 'GTK_mikeFramework', or something, as its easily possible to visualize multiple ways of doing this. especially as I would thing GTK_GladeFramework would be an obvious alternative.. Config/ini settings This is extremely difficult, as applications may want to use xml, ini file or any other form of configuration storage. - I would break out the config dialog stuff into a seperate class, and just use a more generic $options = PEAR::getStaticProperties(get_class($this),'options'); or $config = PEAR::getStaticProperties('Config','singleton'); $config->getValue('/somesection/abc'); But I would break out the show ConfigDialog method into another class.. - a configuration widget.. or something. GTK_Dialog_Config ... etc. Modules ----------- I would recommend that all modules extend a base class - which is where you can document a standard API - this is a mistake that PHPmole made :) Dialog --------- try using options array rather than large lists of constructor args eg. $xxx = new GtkLoginDialog($text,array(

               'level' =>  $level,
               'userMax' => $userMax,
               'passMax' => $passMax,
              'okCallback' => array( )
               'cancelCallback'=null)

$xx = new GtkLoginDialog($text, $level, $userMax, $passMax, $okCallback=null, $cancelCallback=null) This is more common in PEAR, and usually helps readability etc. Regards Alan Michael Dransfield wrote:

Thanks for the tips Alan... I have put together some basic classes, which I have used to generate a simple GTK application. GtkApplication

        The basic application.  Generates a window with menu, button menu, main window and a status bar.  GtkApplication contains routines to help with configuration (or did until the Config class was completely changed ;).  It automatically loads a gtkrc file used to style the application.  The main Class loads modules which will contain most of the code for the work of your application.  Modules can be added to a program later to extend its functionality.

GtkUserDialog

        A base class which has child classes GtkOKDialog, GtkOKCancelDialog and GtkLoginDialog... All do the obvious things

GtkWizard

        A class to create wizards.  Clicking on new in the test application will generate a wizard, the code to do it is in the testModule2.php file.

Please have a look at the classes that exist, are they the type of thing that could be included in PEAR, and are there any improvements / additions that could be made. I am planning a GtkForm class which I hope could be similar to OOH_Forms There is a zip file of all the classes along with a test script here... http://www.blueroot.net/scripts/php/pear/Application/Application-051002.zip At 08:23 02/10/2002 +0800, Alan Knowles wrote:

Sounds really great - not sure where my time is to help out on this.. but heres a few ideas/suggestions.. Regards Alan Michael Dransfield wrote:

I am looking into the possibility of an (GTK) Application framework for PEAR, something like NetBeans Platform for java (www.netbeans.org). I would like the groups thoughts on if this could be done and what would need to be included to make it easy to write applications. I am thinking that there would be a base application which would set up the main window (menu and status bar etc) and then additional modules which can be loaded to provide additional functionality (user authentication, text editing facilities). People can write additional modules which can also be contributed to PEAR.

I would class that under glade tools : based on the existing work done in this area... - Glade emulator -for bugging Win32 .. although this may not be needed in GTK2, we'll have to wait and see.. - Tools to Auto create object Vars/Callback methods by parsing Glade XML files. I guess a bootloader = eg. load up a glade window, do some depnedancy checks = for a base class to be extended. Menu tools - simple ways to create add to menus... maybe

Below is what I have managed to come up with so far. Please feel free to comment.

Dialog Class.. - I would think a generic dialog class would go before wizard.. (ok, cancel) - set up parent/child relationships.. - add callbacks to it..

Wizards

    - Ability to load a number of frames along with actions to be caried out at each click of the next button.
    - Clean-up facility if cancelled.

Sounds Ok, not sure what is meant by clean up.. -

Authentication

    - Taken care of with PEAR Auth package, would probably need extending to show login box etc.

The idea may be to abstract the Authentication Part into Auth, and the display parts into Auth_HTML or HTML_Auth, GTK_Auth.. which rendered login boxes..

Logging

    - Mostly catered for in pear already.

Modules

    - Ability to dynamically load gui and menu items along with their relavent actions.
    - osCommerce (oscommerce.org) has a nice module system which could be partly copied

Not seen that.. I did a stupid thing a long time ago - converting osCommerce into a functional base PHP app, - never again :) The two module approaches I've seen are to have a module directory that is parsed (eg. opendir()) to find available modules or just list them manually in a config file....

Auto Update

    - Either using a diff system or replacing whole files
    - Ability for the user to turn this feature on and off

Really should start looking at the bcompiler/phpembed combination on windows now.. - this is now all in CVS, and provides the posiblity to do exe files for PHP.. - this would be the ideal distribution method for desktop stuff.. - in which case diffs are a bit difficult..

Form generation / validation

    - Something like OOForms, im not sure if this could be extended or if it is easier to write a seperate class all together (probably easier to do this)

yeah - this is a bit complex.. I dont know OOForms that well, but I did it in phpmole, to the extent of mapping Data to Glade Forms

UI Features

    - File loading and project routines to ease loading of files

theres something in the pear gtk installer that does directory browsing as a 'addin widget' - this could be grown to do the whole set.. - dir/file etc.

Config / Options

    - Config classes exist in pear which can be extended to provide a user interface to the options

pear installers's gtk config stuff is not too bad.. - provides a Aqua like design for configuration.

Caching of remote database

    - For offline working.  Maybe can include an offline update facility where changes locally are queued until the user is online and updates to the remote database can be done.  Hashes of each row could be stored and compared at update time to check that no other changes have taken place.

Cheers Mike

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php