The most important thing for a developer to be able to do to unleash all the power of Morfik is to understand HOW things work in the Morfik Framework. This understanding will open new possibilities and new paths that you, as a developer, can explore and exploit in order to create richer, more sophisticated applications.
Once you have created Forms, Reports, and code modules for your application, how do they behave at runtime? It is this knowledge and how to use it to your advantage that we hope to cover in this section.
The Morfik Application Framework
Most modern software development tools offer the developer several key things: a programming language (or more than one), an integrated development environment (IDE), a function/class library and some 'compiler magic'. But just what is this 'compiler magic'? Well, it's the stuff that the compiler does for you to unburden you from having to do it yourself. This is the kind of stuff that you generally take for granted in how a programming language works, but which has a huge impact on how your application works and how much work you have to do to get it to do what you want.
In order to do its magic the compiler relies on the presence of a special software library. The default, built-in behavior of this library is overridden or specialized by the compiler to provide specific functionality for a given application. This special software library is known as the Morfik Application Framework.
The Morfik Application Framework defines the overall flow control for the application and provides a default behavior for most common operations. The Morfik Application Framework allows the control logic, data validation and even business logic to be handled by browser-side code. This makes for a much richer end-user experience with much better interface response times than traditional web-based applications.
The Ajax component of the Morfik Application Framework
Even though you really do not need to know what Ajax is, in order to use Morfik, it will help you better understand how Morfik manages to accomplish some of the things you see being done by your application (these might look a bit like magic to Internet old-timers). Anyone who has been using the Internet for a couple of years is, by now, quite accustomed to its page-centric model. This is where whenever you click on a link or option the entire page you are working on is substituted by another, sometimes even by the same one, but with information that is a bit different.
Ajax is label for a way of using a set of technologies which have been around much longer than this new moniker. These technologies, used for the specific purpose of creating dynamic web applications, started to receive world-wide attention when two events occurred: the name Ajax was introduced by Jesse James Garret in an article and Google came out with a site/application called Google Maps. Google Maps used these technologies to great effect when creating a totally simple and at the same time intuitive and dynamic interface for the user to interact with maps. There was no need to download enormous quantities of information that was not needed, and this greatly increased the usability of the site.
So what really is Ajax? Some people have said that is a technology, others that it is an architecture, but in reality it is neither of those. It is not a technology in itself, but a way of combining pre-existing technologies. It is not an architecture, but it can be used to create one, as Morfik has used it. So, Ajax is a way of using a certain set of technologies which would then, in my dictionary, qualify as being a technique or methodology rather than a set of technologies, and it can be used as part of an architecture, while not being one.
If you are thoroughly confused now, don’t worry. It will pass.
The duality within a single application!
Web applications have two distinct sides: the browser side and the server side. While the browser side is concerned with the way information is presented to the end user, the server side has been about application control logic, data validation and business logic. Although these two sides have vastly different characteristics, they come together at run-time to represent one single application! Due to the fact that these two sides of a web application are so different most development tools only deal with one side or the other. This means most web application frameworks also follow the same pattern; they are written for one side or the other! Consequently, web developers have been left to live with this duality with a cacophony of different tools, standards and languages that must be used to create these two very dissimilar parts of the same application.
When you want to create a totally new application, from scratch, Morfik brings a totally different vision to this scenario: a vision of unity. To better understand how this is accomplished and how to benefit from this, it is important to realize that Morfik does not change the nature of web-based applications, so your application is still composed of two parts—browser and server sides—but what they do and how you build them is radically different from other tools.
The Morfik Application Framework High-level Objects
In developing Morfik Applications you will come to deal with two very different kinds of objects. Let’s name these Common Objects and High-level Objects. What is the difference between them?
Morfik Common Objects are objects that are created just like any class defined in common OOP languages such as Java, C# and Object Pascal. In fact you can create them in the Morfik AppsBuilder using any one of those languages, as well as BASIC. Common Objects work no differently in Morfik than they do in any other language.
Morfik High-level Objects, on the other hand, are much more complex entities which have more than one set of code and data representations and which get special treatment in the Morfik Workspace along with some 'compiler magic' to make them easy for the developer to work with. These objects have both a server and a browser-side code image, which will allow these objects to work on both sides of the XApp, whenever appropriate. These are not your everyday, OOP language objects but much more complex entities that are, internally, composed of two different sets of code (for the server and the browser), an HTML (or XHTML) representation and an XML representation of its data.
High-level Objects get special treatment in the Morfik Workspace; therefore, we can know their base types by mainly looking at the Workspace itself. Morfik High-level Objects are generally referred to as documents in the Workspace and treated as such through its interface. Let’s have a look at the most commonly used High-level Objects in the Morfik Framework.
Every time you create a Form in the Morfik Workspace you are actually creating two Common Object classes in your code: one for the server and one for the browser side of the application. Both of the classes will be descendant from a Form class, but they will be two different Form classes that are specifically designed for use within a browser or on a server. Through special treatment by the Workspace and the compiler these classes are combined into what we have been calling a High-level Object, which has both a server and a browser-side representation. Both of the ancestor classes for your Common Object classes are part of the Morfik Framework.
A Report is another kind of Morfik High-level Object which receives special treatment in the Morfik Workspace, allowing you to very easily create richly detailed reports. Reports are entirely generated on the server side of an application. Though Reports seem to be very similar to Forms at a first glance, they differ significantly. While Forms live a double life, being represented by two Common Object classes (one on the server and one on the browser side of the application) Reports are totally server-based. This means that there is only one class that handles all the customization of the Report. In a Morfik XApp the only kind of document in which all the logic rests on the server is the Report. By design Morfik Reports are entirely processed on the server and then transferred to the browser in the print-ready PDF (Adobe’s Portable Document Format) format.
WebMethods are also High-level Objects, having both a server and a browser-side Common Object implementation, very similar to what happens with Forms. This kind of Object is a very interesting addition to the Morfik Framework. This Object allows for the quick implementation of 'functionalities' on the server side of a Morfik XApp which can be called, in a very simple manner, from the browser side of the application.
As with Forms, WebMethods are divided into two separate classes, the browser side and the server side. There are basically two 'WebMethod' classes in the Morfik Application Framework—one acting as client and the other acting as server. When you are creating your own WebMethods you are creating two descendants of these classes, one of each, which together will comprise your High-level WebMethod Object.
A Morfik Table is another High-level Object in the Morfik Workspace. It is formed through the combination of three distinct entities. Every time a Table is created, a SQL Table is added to the application database, a descendant of the TTableProvider class is also added and finally two WebMethods are automatically created to publish the content of the Table.
The browser-centric nature of Morfik applications
Unlike the server-centric architecture of current web applications, Morfik applications are browser-centric. Amongst other things this means all the user-interface events are handled within the browser. The server-side events are program generated and not related to the user interface. The browser-centric nature of the Morfik application model makes the ‘glue logic’ that is required for combining various user interface elements a lot more intuitive than the current prevalent server-centric models. Events such as 'click', 'mouse down' and 'mouse move' are all handled within the browser similar to the visual programming environments used for desktop applications. Within the associated event handlers of such events lie the bulk of the glue logic needed for binding various elements of the user interface.
The Morfik Application Framework programming model
The best way to understand the underlying structure of a Morfik application is to compare it to a desktop application. Applications that are created by Morfik have a similar binary structure to desktop applications; however, unlike desktop applications they do not use the native user interface elements of the underlying operating system. Morfik applications use the standard web browser to implement their user interfaces.
On the browser side the execution happens within the context of a single browser page. The browser side of the Morfik framework acts in a similar fashion to Delphi’s VCL or the Microsoft MFC in that it consists of wrapper objects that wrap around the underlying operating system user interface elements. In the case of win32 these objects are Windows controls whilst in the case of Morfik these are elements are found in the browser HTML document structure (DOM) .
The browser-side and the server-side code in a Morfik application are characterized by two distinct programming models. The server-side code is highly concurrent while the browser-side code is completely asynchronous. Whilst the Morfik IDE removes many of the programming chores associated with these two types of programming, an understanding of these two concepts is fundamental to efficient programming within Morfik.
The majority of desktop applications are single-threaded and almost always synchronous. Apart from the user interface thread there might be a small number of worker threads that do a number of time-consuming activities. Most small to medium sized applications on the desktop are run on a single thread. On the other hand, the server side of a Morfik application is heavily multi-threaded. Every request going to the server runs on a separate thread.
Morfik’s implementation of a web application uses a completely stateless approach to the programming of the server side. This means the data within the server-side code does not change during the course of execution of the program. Any data that changes is committed to the database or will be lost. This to a large degree mitigates the onerous requirements of multi-threaded programming. This approach needs to be followed by application developers. Global variables must be avoided as much as possible as they are normally not ‘thread safe’ and they would break the stateless model of Morfik applications. However, global variables are required one has to use the appropriate programming techniques for thread synchronization.
The programming model for the browser side is, on the other hand, completely asynchronous. This would particularly feel different for those who are accustomed to traditional desktop applications that are highly synchronous. The main cause of this is the HTTP communications between the browser side and the server side. Sophisticated activities within the browser side often require multiple calls to the server side; however, every time a call is made to the server side a ‘callback’ must be set up so that the execution of the task could continue. Since the ‘state’ of the execution is not kept from the point that the call was made relative to the point where the callback function is invoked, it is the responsibility of the programmer to manage the execution state within the browser. Morfik IDE and the AJAX code hides most of these activities from the programmer; however, there are situations that may require the setting up of the callback functions as well having to preserve the context of execution.
- Understanding the key operations within the Morfik Application Framework
- URLs in a Morfik Application
- HTTP Request processing in details