lbDMF - Distributed Multiplatform Framework

lbDMF is a component based multiplatform framework.

The current project information:

"A component based programming framework. This project is aimed to support various target frameworks. A wxWidgets based GUI application is the major sample which also provides rapid database GUI design with UML import and export (db reverse engineering)."

In the past:

That was not the intention as of the beginning of this project. The beginning was a circumstance that a commercial development tool has been discontinued and I was confronted with the following problem: What do I with my old code and what do I if this happens another time with another product. That time the project was born, but very far from an application.

In the beginnings I had to create a framework from scratch. That is still part of the project as it contains 'Framework' in the project name. The part for the word 'Multiplatform' filled a framework I 'used' to create the frontend - the GUI for an application that may use a graphical frontend. It is the famous wxWidgets framework. So my framework uses a framework and that's why I could not use multiplatform or framework twice. The wxWidgets framework I use is the platform I use, but it may not be the one alone. That's why I see wxWidgets in the word 'Multiplatform' - hehe :-)

Why do I use two frameworks, or my own and another?

The reason was due to the ability to change the 'underlying' - or better overlying GUI layer without changing the layer I write my code for the bussiness logic. A practical sample is a TUI framework well known earlier in the PC history - Turbo Vision. In the past I have presented sample screenshots showing similar database forms in TUI mode.

So the real project name may this: Distributed Multiframework Multiplatform Framework. Too long :-)

The current goal:

The more time I spend the project evolves in features and aims changing. Currently the main goal for this project is to make it production ready and probably fork it to keep the original project for it's origin aim and a new project to follow the aims of the main sample application.

The primary sample application:

The current goal is to create a modular application that can be configured in the database. Currently the default database is based on Sqlite. With Sqlite it is possible to easy try out the main demo application, that really is a dynamic application whose configuration gets setup if the application starts the first time. This dynamic application - a prototype - is used to help you design database applications. And to see it in UML, just export the main sample application as an UML model and have a look at it with BoUML.

When you start designing a database application, you should use UML modelling tools like BoUML. BoUML is tested and the documentation is based on that tool.

After you have done your first design in an UML tool and imported it into the main application, you can test the imported application as it also has created a database for you if you accepted that. You test the application by restarting the main application after deactivating the option 'Autoload application' in the Edit menu. If the first design matches to the ideas you have, then you have the option to save the design as an XML file or as an UML (XMI) file while that application runs. From the UML file onwards your development steps go further in detail.

If you have modified the exported UML model, you could reimport the model and try out the application. With the import and export capabilities to and from UML you also have a reengineering functionality that you could use to create database applications based on existing databases. This has been tested with the database of the Postbooks application.

There is an optional feature that enables you to use a client/server database. Tested is the PostgreSQL database, but also other databases may be possible due to the ODBC driver the application can use.

In the future:

The part 'Distributed' comes across when the two frameworks are understood as different layers. Between these layers a crossing of the boundaries of a 'Computer' to another 'Computer' may happen. The goal to achieve this should be reached by the following question: Who is responsible for what?

The upper layer serves as a 'GUI server'. It provides an API to create a form, menu, statusbar or a toolbar and functions to populate it. This is done by the application using the wxWidgets framework. The next layer is the application logic that is written in my own framework and thus I do not rely on other frameworks. The connection between that may either be done by dynamic loading of DLL's or shared libraries or wrapper around that DLL's or shared libraries for crossing the computer or process boundaries (COM, CORBA or similar things may be used). But this is really future, but it was an idea from the beginning of the project, because the modularity of the framework is based on techniques comparable to COM or CORBA.

I hope you will get any useful information about this pages and understand why I do things how I do them.

You will read more about the project in the near future as this site currently will be created.

Thank you for reading and thank you for staying tuned. Also have a look at the news page.