Bond 0.4x Project Page

Bond 0.4x was last updated near the end of last year, and has since been replaced with the Bond 2.0 project, which greatly reduced the amount of general programme knowledge required to create great database programs. We have kept Bond 0.4x documentation and other resources here.

Bond UI

Bond 0.4x User Interface background information; here as an inspiration for what we plan for Bond 2.x ...

Bond Web

BondWeb is a server that spawns applications written in Bond and runs them in UIHTML mode. The applications, which may normally run as a GTK application will instead appear as a dynamic web site using standard HTML forms.

While it would have been nice to tie in directly to Apache instead of having to write our own web server, there were a number of problems involved in this that were only solvable by writing our own web server. I recommend you run this web server on a different port (i.e. 81) and have Apache on port 80. Then configure Apache to redirect all traffic to port 81 on certain URL's.

At the moment this component isn't available for download.

Bond uihtml plugin

The more interesting, HTML web application version of Bond. Using this library you can turn your applications into web server applications without the need to change any of your existing code. It will translate all the user interface calls from Bond and your application into appropriate HTML pages to serve out.

This needs to be used in conjunction with the BondWeb server to manage user interface sessions and callbacks, though you can use BondWeb with your Apache web server.

Bond uigtk plugins

Bond has the ability to use different widget sets on its front end. Once you've written your application in Bond, you are not tied to a specific platform. When you link against Bond you can choose at run time which envoriment you are running under.

The UIGTK library uses GTK and LibGlade components for the Gnome desktop to make your widgets data-aware. It principally a wrapper around libglade and GTK-1.2. A wxWindows version is planned in the short term future so Bond applications can be run under windows.

Bond uiwxwin plugin

The wxWindows support is well underway. When complete, bond will support all the GUI's that wxWindows supports, this includes windows, macOS, and non-GTK widget sets under unix.

Documentation

Some more documentation for Bond 0.4x below.

How it works

Bond is a library that you link your application to. When you initialise Bond it will display the relevant windows, and take control of your application.

Overview of Bond

Bond will gather information from your backend database. It will also parse a Glade XML file to work out how the application should come together. Ideally you shouldn't need to do any coding other than call bond_init() and bond_main(), though the option of writing your own callbacks is there if you want it.

If your backend database is designed well (constraints, default values, etc.), and your user interface is well suited to that database (appropriate labeling and widget names) then Bond shouldn't have any trouble bringing your application to life. Widgets will become data aware and point to fields or tables in the database.

API

Documentation effort at the moment is on the weak side as our primary concern is development. We would really appreciate some help here if someone wants spend some time here hacking together examples, howtos, etc.

API Documentation Bond 0.4x

The Bond api.c/.h files is the main API, and 95% of the time all the functions you will need to use are covered in this file. Calls such as bond_showform("GTK window name"); and bond_showformbyform("form to open","where you're opening it from"); are some of the main Bond functions you would need to use. testsoldier.c is a good place to start if you want to see how an application is written in Bond.

API Reference Guide 0.4
Overall system design
New Bond Dropdown Design Note by Francis Lee

The Backend Database

Because traditional relationship databases do not hold information that is critical for Bond to work, like how objects relate to each other, Bond requires an application object orientated server.

At the moment Bond talks directly to PostgreSQL. In the future support for GnomeDB will probably be added. Within PostgreSQL you can create views to your tables that describe the fields you want on a window form. This is then picked up by Bond and translated into information to work out which widgets are data-aware and what their data source is. Views also need to be created in PostgreSQL to define the relationships between objects. Bond will only work with PostgreSQL version 7.0 and higher; future supported databases will have to be similarly compatible.

When I design database applications I do it in two parts: I design the database backend of how the objects relate to each other and what is contained in each of those class objects; then I design the user interface of how the forms interact and the user processes flow, using tools like Glade or Borland Builder.

Traditionally after this is done I do all the coding to make the forms I have developed work with the database backend and implement such things as searching, drop down boxes, loading of forms, etc.

The central idea behind Bond is that we can skip that development phase and just design the front and back end and let Bond do its magic stuff. Let it work out the those nasty relationships, handle that data retrieval, and build the drop down boxes etc. With Bond your source code files should be relatively small.

Developing Bond Programs

Bond still needs certain things like coded like callbacks for buttons. And you may find specific widgets in your forms will need special attention because they do something a bit out of the ordinary.

Its a bad idea to use the code generation in glade. Bond was designed to build applications at run time, not compile time. Code generated by glade will not work with bond without great modification. If you need a quick approach its a lot easier to take an already existing bond application and copy makefiles etc than trying to create from the output generated by glade.

You need to call a bond_init(argc,argv); at the start of your to initalise GTK, bond and bonddb. Then call bond_main(); to enter into the main loop. Create the functions for the signals you created in GTK. In these functions make the nesserary calls to the the api functions you wish to use. Please check out the api.c documentation for these callbacks details.

In your Makefile you need to include the bond source directory and link against the right libraries. Applications like libglade-config --cflags and libglade-config --libs will also need to be specified in the makefiles.
-lbond -lbonddb -lpq
For includes, make sure you specify that you specify to right include directories.(its a I as in includes).
-I/usr/local/include/bond

Designing your graphical user interface

You need to have glade installed, bond only supports the basic widget so gnome controls etc are not important.

The most important thing is labeling and naming your widgets correctly. The names of widgets are used as reference points to try and work out what you really mean. Not all user interface styles work with bond, so its a good idea to see some other glade files developed for bond to see examples what works well.

For a basic start you would label your window forms the names of tables you want. All the widgets inside the form that you wish to show. You can have forms that use different database tables, as long as they are sufficantly broken up into different groups in glade. Use your tables and fields as a guidline of what should appear on each window.

Widget names do not have to be an exact match on fieldnames, for example EntryBox13fieldname would link back to fieldname. Table.fieldname is also a valid format, so in a GtkCList you could have columns that reference other tables by using the naming the label Label123othertable.fieldiwant.

Dropdown boxes can refer to either a field or a the name of a view in the database. If you have a constraint defined (ie a one to many relationship) you can use a dropdown box to handle this. Name the dropdown box the name of the local field which has the constraint and it will pick up from the relationship which items it needs to show.

GtkCLists can refer to another table which a constraint relationship exists, or show all the rows in the current table. If you name the clist to a tablename it will try and show that table by the relationship defined, else it will default to just showing all the current records in the parent table.

Prefixing character zero '0' to a name of an Window (e.g. GtkWindow or wxWindow) has a special meaning. That tells the trigger manager that the window should not be treated as a datasource. In other words, the window widget should be treated it as a database table. The main use of this is when you design an Window which contains a notebook widget (or property page control in other term).

Suffixing character asterisk '*' to the name of a widget has also a special.

As bond progresses it should be less dependent on you designing your glade files in a certain way. And be able to pick widget data sources without having to name the widgets. Also the need for callbacks will slowly be removed and more demanding user interfaces be supported.

License

BOND is licensed under the GPL (General Public License). You can not use BOND with non-GPL code. If you write an application using BOND, then you must release your code under the GPL also.

There is an alternative commercial version of BOND available if you wish to use BOND with a non-GPL application - email sales@treshna.com for purchasing information. This version includes a number of additional features that are not available with the GPL version. The software is released under dual licenses, allowing us to market two different versions of the software.