Packages were introduced with version 2.1 of AppsBuilder, but it is in version 2.2 that they seem to be really maturing. Version 2.2 introduces several new features for packages including package dependencies and nested packages which open up the way for packages to be used as tool for creating modular applications.
While the packages introduced in 2.1 offered the necessary support for the Widgets concept that was introduced at the same time, it did not lend itself well as a tool for organizing your application. With the new features introduced in 2.2 that is no longer the case.
Why create a modular application in the first place?
There are two main reasons why it is a good idea to breakdown your application into packages: to make it easier to find stuff and to make it easier to distribute work within a team. The first one is a weaker as the built-in filtering feature of the Morfik IDE’s project view is quite powerful and makes locating stuff rather easy, if you know what the object you are looking for is called. The second reason, however, is much stronger.
As one of three developers working on creating an application, I frequently find my self having to combine modules from different copies of a project. While it is true that you can manage projects of virtually any size through a good source code management software, I started to contemplate how packages could be used to break up projects into smaller sub-projects.
As it turned out there was a road block on my path to breaking up a large project into several packages in the form of the project’s database. Any items moved to a package would not have knowledge of the database objects that were part of the main project. By the same token, if the database objects were created in a package, forms in other packages would not be able to see them as well. This looked like a problem without a solution, and it was until Morfik Appsbuilder 2.2 came out.
Nested packages to the rescue
With version 2.2 of AppsBuilder came the possibility of having packages being used by other packages and this gave me an idea: What if we were to put all the database objects into a single package and then have all other packages reference that one. As soon as it occured to me I set out to test the idea and it the proof of concept works okay so far.
My first quick experiment made one thing painfully clear though: you need to set out to create a modular application right from the start. The current incarnation of the project I am working on has between 50 and 60 forms, 30 tables, 18 queries and over 15 Firebird stored procedures. Almost all of these items would need to be changed if I were to attempt to break this application into packages. This is basically due to a feature in Morfik which is designed to ensure that name clashes don’t occur between packages created by different developers.
You see, in order to create a package you need to have a Package ticket file. A ticket file can be quickly created from within the IDE itself and it reserves a prefix for your use. This prefix is then mandatory in all objects created within your packages. While the usage of this prefix does prevent two developers from creating objects with the same name, it also precludes the possibility of simply slicing up an existing project into packages as all items that were moved into the packages would need to have their names changed.
For new applications, however, it is a simple matter to create all database objects in a single package that is then referenced by all other packages that are created for the application. When creating packages that reference this database package it is a good practice to flag it as a required package. This will prevent anyone from adding the depedent package to a project without previously adding the required package with the database objects.
Breaking up an application into packages can be quite useful, especially since Morfik’s own form based architecture leads us to create a large number of objects (forms) which are used to compose a larger one. This tends to leave us with several objects which are part of a larger context. For example, in order to create a user management module you might end up with several forms for users, groups, permissions, etc.
You can combine all these objects into a single package and pretty much never see these objects, unless you need to do some work on them.
Have your worked with Morfik packages yet?