Setting somethings straight...

It was recently called to my attention that some people might have an incorrect perception of my relationship with Morfik, so I thought it would be best to make sure everyone got the correct information.

While I did work with Morfik as an advisor and then for Morfik, under contract, for a period close to two years, I no longer have any sort of affiliation with that company.  While at Morfik I worked on some of the business planning, product features design, IDE design and the documentation.  Today I am an active Morfik user.  I use Morfik daily in the construction of two websites and a complex corporate dashboard, multi-application, project.

The fact that called my attention to this possible confusion was that in posting a comment to a blog post I logged into WordPress with an account that was created while I was working for Morfik and which still had the @morfik.com email address listed in its profile.  This lead to the original poster to have thought that I still had some affiliation with Morfik. I have corrected that profile, but it occurred to me that other people might, also, have gotten such an impression.

I am quite proud of having had the privilege to be a part of  a team with such talented professionals as those in the Morfik team.  While at Morfik, I got to know a lot of good people and made great friends.  This however, has nothing to do with with what I write about Morfik.  If I did not believe that Morfik is a great product or if I didn't use it my self, I wouldn't write about it.

Unfortunately, due to communications difficulties, created by geography, Morfik being in Australia and me being in Brazil, I had no choice but to stop working for the company.  Since then, because I like the product and because I believe in what that team can accomplish, I've set my self to organizing communities of users and writing this blog.  I've recently, also, become more active in posting to the Morfik forums as I have been spending a good portion of my time working in actual development.

I hope this information makes my relationship with Morfik clear to everyone.

Interface Building with Morfik: A Treeview like interface sample

In another recent article about interface building I mentioned that it is not difficult to create a treeview-like interface with Morfik, primarily through visual design.   As an example I used a few screenshots from an application that I have been working on but for which I cannot make the source code available.

In order to help anyone that wants to build something similar I created a small sample project that just implements this single feature.  The following picture shows what the sample looks like.

This sample is available for download in all three languages supported in Morfik AppsBuilder 2.2, through the following links:

• Pascal - for Morfik FX
• Basic - for Morfik BX
  
• C# - for Morfik CX
  

This is the first time I have used Morfik FX 2.2 to create projects in the other two languages.  If you have any problem using either the Basic or C# version of the project with Morfik BX or CX, please let me know so that I can look into it.

UPDATED:  There really is no need for the Tree nodes to have the border around them.  How they look is entirely up to your creativity.  I kind of did it this way, in automatic mode, because in my applications I need to have this area well defined as I change the background color for each node based on certain business rules.  

Interface building with Morfik: The database is your friend...

Morfik AppsBuilder is pretty much built around the concept of a data-driven application.  If you can get a specific information set out of the database, you should be able to present it with class in a Morfik application.

Though I've written a thing or two about this topic in the past, I can't stress enough that sometimes it is just quicker and better to do some coding in the database layer of your application.  Sometimes a short stored procedure, which can be written in five minutes will not only yield the desired results but will do so a lot faster than a highly complex query which will take you over an hour to build in the visual designer.

Stored Procedures also offer you the opportunity to return special values for rows which would not otherwise be returned by your base query.

Several times, I've been asked about the availability of a menu control in Morfik.  I mean... How is it ever possible to create a menu without a menu control??? Well... There are several different ways to do it, some faster, others more flexible.  Some are even immediate.  The more observant of you might have already imagined that with a little bit of reformatting that hierarchical representation from my previous post can be made into a vertical menu of the type you quite frequently see used in website navigation.

In order to make a horizontal menu with drop down submenus you can use the new Dropdown control. This is, in fact, used in Morfik's What's New page with great looking results. Do you feel you need to create a menu with more sub levels than that?  Well, it is possible and easy to do so, using the same Dropdown control, however, I would advise you to revise your design ideas as they might be headed more towards a DOS application than a Web one.

It is not that I don't think that Morfik AppsBuilder could have a menu control or a specialized menu editor.  I do however believe that it is much better go ahead and build a good looking menu in a couple of minutes with the available resources and move on to other parts of my application than to dwell on why is it that Morfik R&D hasn't spent a couple of months building a such a menu designer yet.

Morfik's database oriented design has helped me create several reasonably complex applications with very little coding. It does however require that you give some thought as to how you are going to divide up your pages into forms as each form can have its own data source.  It is, in fact, quite common for you to end up building a single page from a large number of small forms, each responsible for retrieving some bit of information and displaying it in the most appropriate manner.

For example, the page you see displayed in the Morfik Debug Browser in the following picture is the end result of combining together seven different forms.  I've placed red lines, roughly indicating where each of the forms comes in.

This is a screenshot of a test version of an application I've worked on recently and using totally bogus test data which tends to leave a lot of blank space in the page, but it should allow you to have some idea of how the structure for the page was created.

Whenever you think you've hit a show stopper in creating your Morfik application, take a step back and reconsider the problem.  Most of the time it turns out that there is a simple solution for your problem if you just approach it from a different angle.

Interface building with Morfik: A hierarchical data representation

In the wake of my previous post I decided to show my dear readers another interesting thing you can do with Morfik, in creating an interface. 

It is quite common for applications to have the need to present users with information that is organized in a hierarchical structure. In creating a desktop application we would use a Treeview control to display this kind of data.  I've actually seen quite a few people asking for Morfik to incorporate just such a control.

Well, it isn't really strictly necessary to have a specialized control to get this sort of representation.   The following picture shows a treeview-like data representation created with simple forms and very little glue code.

 Observe that in this picture the nodes for the tree representation vary in height, allowing for non-cryptic presentation of the information as it does not really need to be abbreviated.  You can, of course, also create more sophisticated hierarchical representations of your data.  The following picture shows a similar representation but with the nodes being color tagged.

This representation can be achieved though the usage of form that opens a new instance of itself in a subform that it contains.  It is essentially a simple recursive algorithm.  In the case of the second picture all that was really necessary was to design the form and write about 25 lines of code.  Sure using a treeview control might require less lines of code, but I sincerely  doubt that you could design a Treeview control have variable color and height nodes, without manually coding the necessary changes.

As soon as I can make the time I'll write a two or three form application to provide a model or template that you can use to quickly make your own hierarchical views.

Interface building with Morfik: Multi column continuous forms

A blog post by a disgruntled Morfik user, complaining about not being able to create anything but the most basic websites without resorting to Web Methods and manual control creation led me to the conclusion that many of Morfik AppsBuilder's most interesting features go by unnoticed  by many.

One of the features that I've seem people make very little use of is the multi-column continuous form.  This kind of form allows us to create interfaces that resemble Morfik's own "Project View"  In an application I've recently been involved in creating, we use this feature for maximum effect.  In one point, for example, we allow the user to choose the icon that will represent a certain entity within the application's database.  The icon selection form that is shown in the following picture was quite easy to create.  The whole feature is actually composed of two forms.

Using nothing more than the MouseOver style configuration we can apply a nice rollover effect to let us know which icon we are about to select.

The same technique can be used to create other kinds of views for presenting information in your application. The following picture, for example, shows how data from several months is presented and color tagged according  to specific business rules.

In order to try out these possibilities just experiment a bit with the ColumnCount proprety of a continuous form.  I recommend that you try it and see what you can come up with.

Morfik 2.2.1.4 update released

Morfik released a new build (2.2.1.4) a few hours ago.  As with last couple of releases, this also focus on bug fixing and adding a few more features to the Form designer.

The continuous bug fixing over the last couple of releases has gone a long way towards making 2.2.x a more stable platform for application development.   At the same time, a large number of new design oriented features has moved Morfik solidly into a camp previously dominated by designer tools, while remaining a developer's tool.  Morfik AppsBuilder is certainly a much more designer-friendly application now, then it was a couple of months ago.

The new status bar in the designer offers some really useful information.  Download the new build and try it out. 

Organizing your application with Packages

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?