Using QNXO for Delphi Applications
as published in on qnxo.com
Summary
When building new, complex applications, it is very beneficial to agree on an overall development framework (set of standards, naming conventions and shared components).  The time it takes to build the framework is easily made up by the "downstream" productivity improvements of framework-based development.  Add generating code using Qnxo to this picture and you will see big savings on your project.  Using the framework and Qnxo to generate the building blocks of Delphi code, we find that we can now build a rather complex screen in a couple of days instead of a couple of weeks.  Where we normally used 3 weeks to build a screen, we now do that in just one week.  About 50% of the timesavings can be attributed to generating the building blocks (both reusable code and starting-point templates) using Qnxo.
Detailed report
In June 2004 we decided to build a Delphi framework for Oracle-based applications.  The way we saw it, that was a lot of code for a CRUD-screen (create-retrieve-update-delete) – or any screen in an application.  That means that this code can be centralized in higher classes and the real screens can be built as descendants of those classes.  While building the framework we decided that:

  • As much code as possible should be in the framework classes
  • As much code as possible should be in classes that can be 100% generated based on the data model
  • The rest of the code should be generated once based on the data model
  • For building the screens we wanted to use as little code as possible

While building the framework we kept these four rules in mind with everything we did.  And during the development of the framework we found that Qnxo was a great helper tool for our framework.  We identified six different pieces of code that all consist of one class that can be 100% generated and one class that is generated as a starting point for the developer to do the layout work and put in the custom code for the application.

The development of a working version of the framework took about one month to complete.  (Frameworks like these are never really "finished", because we are always finding ways to improve it; with Qnxo, we have a product that lets us easily evolve the framework.)  Then we started writing the scripts to generate code.  We took code we had written as a test application while developing our framework, identified the parts that were related to the database (tables, views, column-names etc), and replaced them with templates built with CGML (Code Generation Markup Language).

The next step was to identify the different task-groups and tasks that would build up the application (at least the generated part).  We decided that we needed two major task groups (one to generate once and one to generate over and over again).  Underneath each of these two task groups we identified 3 task groups:

  • Generate the database object code
  • Generate the frames
  • Generate the forms

Underneath these groups we created the different tasks for the different parts to be generated.  These tasks then consist of one or more roadmaps identifying the scripts needed to create the code.

When all of this was in place, we started generating the code so we could start building the application.  We have a rather big application to build (or actually to migrate from Oracle Forms), so generating the code took about 6-8 hours.  That might seem like a rather long time, but if you consider the amount of code generated (about 25 - 30 MB of text files) then that is rather fast, especially compared to writing this yourself.

Now that we have all the generated code in place we can start rebuilding our application.  This is a lot like building with Legos.  We've got a lot of building blocks in place which we have to connect using a couple of short statements.  Using these blocks takes us about 30 minutes to build a screen for a master-detail relation in the database.  Although the layout of the forms is not nice, the screens are working.  Now we just have to take a couple of minutes to do some layout on the different parts of the screen (in the correct files) and then we are done with our master-detail screen.  All the CRUD stuff is working.

As a rule of thumb we calculate one hour for one part of the screen.  That means that we get about four hours to complete a rather simple Master-Detail screen.  That should be easy to do.  Most of the time, we spend less than two hours doing this.  But, when we have a rather complex screen with details in details, the layout of the objects on the screen can take up more time and the connections between the different parts may take a bit more time.  But as an average, it's a good timing estimate.

Now consider building a master-detail screen for yourself.  You'll have to figure out what fields are in a table, what kind of object you want to use for that (an edit box or a memo field).  Then you have to put all these on your screen, do the layout, connect the fields to the database, and implement the insert/update/delete/select statements over and over again.  This takes up a lot of time.
Conclusion

So to conclude: Building applications with a framework is a good thing for productivity.  Generating building blocks with Qnxo is even better for productivity.