Understanding the Morfik Framework
From Morfikwiki.com
The most important thing for a developer to be able to do to unleash all the power of Morfik AppsBuilder 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 that of how to use it to your advantage that we seek in this topic.
[edit] Browser Applications Vs. Web Applications
Morfik Browser Application projects and Morfik Web Application projects share the same browser side framework. Just about everything that can be done with one, can be done with the other with very few exceptions. Whenever there is such an exception, special attention will be called to it.
Browser Applications have very different goals to Web Applications and this should be kept in mind when looking at how the Morfik Framework works. Browser Applications are intended for individuals and companies that have an existing infrastructure and wish to create a new web interface. It is also designed to be used by individuals and small businesses that do not have and quite possibly do not want to have a dedicated server of their own. In this scenario, Morfik Browser Application projects allow the user to create rich websites that can be deployed to just about any server.
Morfik Web Application projects are intended for creating custom, Web-based, applications and data-driven Websites. Our goal is that Morfik AppsBuilder be the only tool a developer needs to create such an application.
[edit] Application Duality vs. Unity
Web based applications have always been divided into two parts: the browser side code and the server side code. Traditionally, the browser side code has always been about displaying information to the end user, while the server side code has been about application control logic, data validation and business logic. Web developers have not only always lived with this duality, but 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 AppsBuilder 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 side, but what they do and how you build them is radically different from other tools.
Morfik differentiates projects into two kinds:
- Browser Projects - These projects are pure browser applications. There is no server side code created for them, in the Morfik Workspace. These applications can, of course, make calls to preexisting server applications or Web Service APIs. Browser projects are ideal for creating static websites, new front-ends to existing systems or small applications for embedding into Facebook or MySpace. These projects can also be accessed and ran on the iPhone.
- Web Projects - These projects contain both the browser and server components of a Web-base application. These projects can be compiled to be an add-on to an IIS or Apache Web server, or as a stand-alone Webserver. These projects are ideally suited for situations where new applications are being created, from scratch, as they allow for the entire project's code to be created within the same project.
While creating a Morfik Application, or XApp as it is generally called, most of your application control and data validation logic will be written for the client side of the application. In truth, the server side of your application, while retaining the capability of handling complex logic, is not called upon to do so, most of the time. The Morfik basic infrastructure, which we shall now call The Morfik 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.
[edit] The Morfik Framework Enters the Scene
So, what exactly is the Morfik Framework? How do I use it? What can it do for me?
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". Most of what I just said is quite plain to understand, but what do I mean by "compiler magic"? Well, its 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.
Well, Morfik provides us with tons of "compiler magic" and services that allow us to create extremely powerful applications in simple and intuitive manner.
To allow you to transfer most of your application’s logic to the browser side of your application, Morfik uses heavily a technique that has recently received the name Ajax, which stands for Asynchronous JavaScript and XML. This technique allows a web application to be totally contained in a single web page, from the browser’s point of view. In response to user interaction, JavaScript code within this document makes calls to the server and receives new parts (JavaScript and HTML code) to be inserted, dynamically into the document.
[edit] What is Ajax?
Even though you really do not need to know what Ajax is, in order to use Morfik AppsBuilder, it will help you better understand how Morfik manages to accomplish some of the things you see being done by your application that 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, 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 a recent name 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, for creating a totally simple and at the same time intuitive and dynamic interface for the user to interact with maps, greatly increasing the usability of the site by not downloading enormous quantities of information without the need to do so.
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 preexistent 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 it 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.
[edit] Morfik and Other Ajax-Based Packages
If you work with IT and haven’t been on a long trip to the moon for the past two years, chances are very good that you’ve heard about Ajax (or at least know that we’re not talking about a house cleaning product) and heard that there are a lot of people working with it. How is Morfik different from everybody else?
Just about everybody who has worked with Ajax, has created a library of JavaScript code that makes it easier for web site developers to employ Ajax techniques to make their web sites more interactive, more dynamic. They have built JavaScript/DHTML controls which can look quite good give an application look and feel to a web site. Some of them have taken the next step and started to make utility functions to handle common problems in complex site development.
Morfik takes all of this, a couple of steps further. First of all, Morfik recognized from the beginning that to build large scale Web-based systems, you need more than controls, you need a runtime library. You need a solid base on which to build. That is where the Morfik Framework comes in: the first powerful, object oriented development framework to be written in a high-level language specifically to run inside the Web browser. While other development solutions were being put together coming from the point of view of strong frameworks for server-side programming, like .NET and J2EE, and being patched together with totally unrelated JavaScript function libraries, such as Dojo and gooxdoo, Morfik was breaking ground in creating a compiler specifically designed for Web applications, a solid object oriented framework and a visual development environment. The combination of these elements gives the Morfik user, a Web application developer, unparalleled flexibility and power. These, in turn, empower Morfik users to create powerful and innovative applications in record time.
[edit] Understanding the Boundaries in an XApp.
In order to gain a better perspective on what exactly the Morfik Framework is, it is important that we understand how a Morfik XApp works. This will give us a unique view of what is handled by the Morfik Framework behind the scenes, many times in a transparent manner, such as handling all the Ajax related code.
Even though it is not immediately evident, when you start working with Morfik tools, as mentioned, your application is divided into two parts which function in very different ways, but which are constructed with the same set of tools. The first part is the browser side code, which will contain most of the control logic for your application and will be responsible for the interaction with the end user.
The second part of you application is composed of the server side logic you have created and will be responsible for handling requests from the browser side of the application and instantiate objects that are sent over to the browser side. In this manner, the server component of your XApp actually works as an Object Server, which instantiates objects which will run on the browser component of the XApp. These portion of the application is only available in Morfik Web projects, created with Morfik AppsBuilder. In the case of Browser projects, all the code necessary to create the Forms in an application is created at compile time and does not rely on specific server side components.
Your Web XApp is, thanks to the Morfik Framework, a combination of an application server, a web server, a database server and a lot of extra functionality that is specific to your application’s logic.
While on the server side of your XApp, the code is totally stateless, in the browser side the application is quite state-full. It is, therefore, in the browser side that your application gets to weave the links and run most of the logic which will define its behavior.
Figure 1 – Composition of a running XApp.
When looking at both the server and browser side of the XApp, as they appear in figure 1, you will notice that you have Object Factories in the server side and Live Objects in the Browser side of your application. While this diagram should give you a better understanding of how an XApp works, it can be a bit misleading, because it gives you the idea that no code executes on the server, but object creation code. That is not true.
What you see represented in figure 1 is a generalization or simplification of how things work. As we will see, behind all their simplicity of use, the Morfik AppsBuilder and the Morfik Framework hide a great deal of sophistication and complexity. It is all this backstage, behind the scenes work, that empowers you to create simple code.
| Stateless Vs. Statefull Server Architectures |
| A stateless server architecture is one in which the server application retains no state control information through its running-cycle. This means that each call made to the server must carry all the necessary information for the server to decide what to do and how to do it, since it does not rely on any previous information. |
| A statefull server architecture, on the other hand, implies that the server does keep track of what its clients are doing and what is the state of each client’s connection. This means that on calling the server you can rely that the server will remember what you were doing previously (and actually remember who you are) and act accordingly. |
| On a direct comparison, the stateless architecture offers the advantages of scalability and reliability. Having a totally stateless server application means you can immediately deploy it to any number of servers and implement load balancing between them. Since there is no state retained on the server, it is indifferent to the clients which server they had previously "talked" to. The fact that the server retains no memory of a previous call also makes it more difficult to end up in a state that will cause the server to crash. |
[edit] Morfik High-level Objects
In developing Morfik Applications, or XApps, 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 is defined in common OOP languages such as Java, C# and Object Pascal. In fact you can create them in the Morfik AppsBuilder using anyone of those languages, as well as BASIC. Common Objects work no differently in Morfik than they do in any other language.
Figure 2 - Components of a Morfik High-level Object at runtime
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.
In figure 2, you can see a small diagram that will help you understand the complexity of the Morfik Objects we are talking about here. 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.
| Note | |
 | It is important to have in mind that all the runtime components of a Morfik High-level Object are generated by the Morfik Compiler and that the developer does not need to know any HTML or XML, or JavaScript for that matter, to work with such an object. |
Figure 3 – Temporary Live Object on the Server Component of an XApp.
If High-level Objects have a Server Component to them, shouldn’t there be a live object at the server side of the XApp? In theory yes, but the Morfik Framework handles dynamic creation and destruction of such live objects as they are required. Since the server does not maintain state information, an object’s server side representation exists only for very brief moments as they perform an action which was required by the browser side of the XApp.
You can imagine that you are creating an application which will run totally inside the browser and that the server is what we could call an "object server" which creates new objects as they are needed for use in the browser side of the application and sends them across the wire to the browser, but you should remember that if you are creating a Web Application (instead of a Browser application), even if small, it has parts that run on the server.
[edit] Which High-level Objects exist in Morfik?
As I mentioned, 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.
[edit] Forms
Morfik Forms are the main interface to your application and, if it is a data-driven application, to the data that is held within its database. They are designed as High-level Objects that mostly run natively in a web browser. This means that anyone who has a modern browser and access to the web, or a local machine that is running your application, can view your Forms. They do not need proprietary software; they do not need to download any further plug-ins. They can simply view your Form, as it is.
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.
Figure 4 – Parameters dialog box showing a large set of them defined for a form.
When you create a new High-level Form Object, you are creating your descendants of the Common Object Form classes. You are creating two entities which will have very different behaviors at runtime but which, at the same time, are very tightly integrated, thus representing the High-level Object. When, for example, you add items to a Form’s Parameters property, they are added to the respective properties of both Forms. At runtime, Morfik’s Framework makes sure that whenever an event is triggered in one of the classes, the correct, updated, values are transferred from one side (browser or server) to the other. This ensures that no matter where your code is running those parameters hold the correct, valid, values.
A Form’s parameters are, therefore, very important since they are shared between the server and browser sides of the XApp and thus becoming the path to keep information in synch between the two sides of an application. In this way you can write applications that have complete knowledge of their current state stored on the browser side, making the server completely stateless, but which you can program as if that information was on the server.
Looking at the parameter list that is shown in figure 4, you will notice that some of the parameters appear in a lighter color. These grayed items are either system parameters, defined for all forms, or parameters of a query which has been defined as a data source for the Form.
Figure 5 - Form parameters cross the browser/server border.
[edit] Forms and Data: a tight coupling
In the Morfik Framework, Forms and data are very tightly coupled. Each Form has a DataSource property which can be directly assigned a Table or a Query, as defined visually in the respective editors. What does this mean? It means that Morfik has made the leap of faith that almost all modern applications use some sort of database and has decided to make data access a central tenet of the Framework and not an add-on. Though you still have the a DataSource object as a property of your Form, its use and customization is very tightly integrated with the other classes and the Workspace itself.
When you create a Query, in Morfik’s visual query editor, you can specify query parameters which you can then take advantage of to generally reuse the query in different situations. Whenever you assign such a Query as the data source of a Form, its parameters will get added as parameters of the Form. What this means is that whenever you pass parameters to the Form you can actually be passing parameters to the underlying Query, also.
| Note | |
|
| Although originally created with server side support in mind, data access support is present in Morfik Browser Application projects too. Browser XApps have XML Data Sources which allow them to use most of the data-aware features of the Morfik Framework for displaying information. Data is stored in XML files and is read-only. |
[edit] SubForms
The Morfik tools work with a type of control, the SubForm, which is very frequently used in all sorts of different manners. SubForms are particularly useful for the creation of complex interfaces where parts of a page change without the need to reload the entire page.
SubForms are very important in that they allow the developer to place one Form Object inside another, thus allowing for the construction of very rich interfaces. In essence, SubForms allow you to transform any Form into a control.
[edit] The OpenForm Function
Though the OpenForm function is not a method of the class Form, it is heavily used for opening forms inside the SubForm components or in place of the current Form.
Following is an example of the usage of the OpenForm function which is shown in greater detail in specific topics.
OpenForm('eMailProductForm', 'Index:MainArea', '');
In this example the eMailProductForm is being ordered to display inside the SubForm MainArea of the Index Form. The empty string in this call is a parameter which allows for the passing of parameters to the Form which will be opened.
It is important to have in mind that a call to the OpenForm function is totally asynchronous. As you can see in the Pre-fetching Forms topic of Working with Forms, you can call the function several times in a row and you will start the download of several Forms at the same time.
For developers used to working with other class libraries, this way of calling up a Form, which relies on a function call instead of on the Form’s methods, might, at first, seem strange. Morfik’s OpenForm function, in reality, relies on the Form’s methods and uses syntax which would look quite familiar to those who come from a Delphi or Visual Basic background. The reason for the function’s existence is to actually hide away the complexities associated with the asynchronous nature of a "web" application. In this way, OpenForm actually simplifies the developer’s work by handling this asynchronous nature without letting any of this show through.
[edit] Intelligent Form Caching
The Morfik Framework implements its own, intelligent, Form caching at the browser side of your application. It is this mechanism that allows you to pre-fetch Forms is described in in specific topic, thus allowing for a much faster end-user experience while accessing your website or online application. It is important to understand that this caching mechanism is in no way related to the browser’s own cache. It is entirely implemented by the Morfik Framework and comes into play when your application’s first/index/home form is first loaded.
OpenForm Syntax
OpenForm(form, context, parameters);
| |
| |__ blank - new browser window with new instance of script process (AJAX engine)
| |
| |__ same - same browser window with new instance of script process (AJAX engine)
| |
| |__ FormInstanceName:SubformName[(bandindex)]
| | | |__ if not specified it's set to zero
| | |
| | |
| | |__ special strings: '_' ('_' denotes the containing
| | subform)
| |
| |__ special strings :'self','parent','top'
|
|__ URL (this will result in a new instance of the script process to be instantiated)
|
|__ instancename:classname
|
|__ classname (in this case the instance name is implicitly set to be the same as
the class name)
If you want to explicitly use the Morfik Framework’s intelligent cache mechanism in your application, you can do so by specifying the special parameter "OpenMode=DONOTACTIVATE" in the third parameter position of the OpenForm function as shown in the example below:
OpenForm('Form2','Self:MainSubForm','"OpenMode=DONOTACTIVATE"');
For more information, please see Working with Forms.
[edit] Reports
A Report is another kind of Morfik High-level Object which receives special treatment in the Morfik AppsBuilder workspace, allowing you to very easily create richly detailed reports. As reports are entirely generated on the server side of an application, they are only available in Web Application projects and not in Browser Application projects.
A Morfik AppsBuilder Report is the most effective way to present your web application’s data in a printed format. This is because you have control over the size and appearance of everything on a report. Your design canvas directly corresponds with a single A4 or Letter standard sheet of paper. You can, via the Report’s properties change such details as margin size, the number of columns, the page breaks, and so forth. As you design you report you are creating a new class, descendant from the Report class that is a part of the Morfik Framework.
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 AppsBuilder reports are totally processed on the server and then transferred to browser in the print-ready PDF (Adobe’s Portable Document Format) format.
Morfik AppsBuilder Reports are created natively as PDF documents. This means that they can be read via the web browser through the Adobe Acrobat Reader. The WYSIWYG (What You See Is What You Get) nature of PDF documents make them perfect for printing. Your reports are printed in exactly the same manner in which they are shown. This method of printing is universal over all platforms, computers, operating systems, and printers. That is, virtually anyone can print a Morfik Report without having to download any extra pieces of software, due to the ubiquity of Adobe’s free Acrobat Reader. If a user does not have Acrobat Reader, it can be downloaded for free.
Morfik reporting is built around a sophisticated report generation engine that allows you to create documents at run-time that are not only data-driven but fully utilize features such as sorting and grouping, which developers have come to expect from packages such as Crystal Reports and Microsoft Access.
[edit] The OpenReport Function
Just as you have the OpenForm function for bringing up Forms, there is an OpenReport function for handling reports. This function works very much like the OpenForm function. Below you can see a simple example of how to use it.
OpenReport('RptContactsList','');
As it happens when working with Forms and the OpenForm function, the OpenReport function’s main purpose is to make the developers’ life easier by hiding away some of the complexities related to the building an applications interface inside the browser.
For some additional information, please see Documents Overview.
[edit] Web Methods
The Web Methods 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, Web Methods are divided into two separate personalities, the browser side and the server side. There are basically two "WebMethod" classes in the Morfik Framework, one for each side of the application. 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.
Differently from Forms, whose primary function is browser specific, Web Methods are very much server focused. A reasonable analogy would be to compare them with stored procedures in databases, as Web Method code is primarily intended to run on the server side with the browser side code being intended to treat the returning call. Due to this characteristic, Web Methods can only be created in the Web projects of Morfik AppsBuilder.
Web Methods are the methods published by your XApp, which is in itself a Web Service. The WebMethod classes allow you to easily create server "functions" that can be easily called whenever necessary. This is done without exposing the developer to any unnecessary complexity.
Though normally associated with a server-side functionality, within the realm of your own application, called from the browser-side application logic, the server implementation of the web method can be directly called from another web method.
Listing 1 – Browser side code for the @ARITHMETIC webmethod@
namespace @ARITHMETIC webmethod@
{
public class @ARITHMETIC webmethod@ : WebMethod
{
published bool Browser;
published double Value1;
published double Value2;
published string Operator;
public override void HandleResponse()
//Performs arithmetic operations
{
double d;
// If "Browser" parameter is False the function ends.
if (!Browser) return;
// If operator is "Add" then performs addition operation
if (StringsEqual(Operator, "Add"))
d = Value1 + Value2;
// If operator is "Subtract" then performs subtraction
// operation
else if (StringsEqual(Operator, "Subtract"))
d = Value1 - Value2;
// If operator is "Multiply" then performs Multiplication
// operation
else if (StringsEqual(Operator, "Multiply"))
d = Value1 * Value2;
// If operator is "FloatDivide" then performs division
// operation (results a float type)
else if (StringsEqual(Operator, "FloatDivide"))
d = Value1 / Value2;
// If operator is "IntegerDivide" then performs division
// operation (results an integer type)
else if (StringsEqual(Operator, "IntegerDivide"))
d = Round(Value1) / Round(Value2);
// If operator is "Remainder" then performs a mod
// operation resulting the division remainder, an integer
else if (StringsEqual(Operator, "Remainder"))
d = Round(Value1) % Round(Value2);
// Shows the arithmetic operation result
ShowMessage(FloatToStr(d));
}
}
}
Listing 2 – Server side code for the @ARITHMETIC webmethod@.
namespace @ARITHMETIC webmethod@
{
public class @ARITHMETIC webmethod@ : WebMethod
{
published bool Browser;
published double Value1;
published double Value2;
published string Operator;
public override void Execute()
//Performs arithmetic operations
{
double d;
// If "Browser" parameter is True the function ends.
if (Browser) return;
// If operator is "Add" then performs addition operation
if (StringsEqual(Operator, "Add"))
d = Value1 + Value2;
// If operator is "Subtract" then performs subtraction
// operation
else if (StringsEqual(Operator, "Subtract"))
d = Value1 - Value2;
// If operator is "Multiply" then performs Multiplication
// operation
else if (StringsEqual(Operator, "Multiply"))
d = Value1 * Value2;
// If operator is "FloatDivide" then performs division
// operation (results a float type)
else if (StringsEqual(Operator, "FloatDivide"))
d = Value1 / Value2;
// If operator is "IntegerDivide" then performs division
// operation (results an integer type)
else if (StringsEqual(Operator, "IntegerDivide"))
d = Round(Value1) / Round(Value2);
// If operator is "Remainder" then performs a mod
// operation resulting the division remainder, an integer
else if (StringsEqual(Operator, "Remainder"))
d = Round(Value1) % Round(Value2);
// Shows the arithmetic operation result
ShowMessage(FloatToStr(d));
}
}['Published=False'];
}
Listings 1 and 2 show the implementation of a WebMethod in the C# language. In order for you to use such a WebMethod, you need to call it using the RunWebService function. Listing 3 shows the Browser side code of a Form which demos the use of this function.
Listing 3 – Browser side code for the @ARITHMETIC form@.
namespace @ARITHMETIC form@
{
public class @ARITHMETIC form@ : Form
{
published TextEdit Value1;
published ComboBox Operator;
published TextEdit Value2;
published Button Go;
published CheckBox Browser;
published message void GoClick(TDOMEvent Event)
{
/*
Run Web Service calls a Web Method named "ARITHMETIC webmethod" to perform
the arithmetic operation passed as string on parameter Operator with Value1
and Value2 parameters. Browser parameter indicates if the server or browser
part will be executed.
*/
RunWebService("ARITHMETIC webmethod",
"""Value1=" + Value1 .Text + """," +
"""Value2=" + Value2 .Text + """," +
"""Operator=" + Operator.Text + """," +
"""Browser=" +
BooleanToString(Browser.Checked) + """");
}
}
}
For some additional information, please see Working with Web Methods.
[edit] XApp – The Morfik Application High-level Object
All that we have been seeing in this chapter occurs under the direction of an XApp and this term has been frequently used throughout this text. An XApp is an object of the TXApp class that represents the Morfik application, or better yet, two objects of the two TXApp classes that exist in the Morfik Framework. These objects "organize" how things work in your application. It is rather interesting that though a Morfik application is essentially a browser-based application, meaning an application that runs mostly inside the web browser; the TXApp class has as much a double personality as does the Form class.
Let us take a quick look at some of the major features and functionalities of the TXApp class both on the server and on the browser side of your application.
[edit] Server side XApp – Your binary application
On the server side, the XApp is your application. It represents your executable and has events related to its start and shutdown. It is also responsible for interfacing with the Apache core library that handles the basic web server functionalities of the application and for launching a web browser, if starting as a service.
[edit] Events
The TXApp class offers a pair of server side events which you can use to trigger special actions when the binary application starts up and shuts down.
[edit] OnStartUp
This event is triggered when a XApp is launched or loaded as a service. It happens once in the execution-lifetime of your application.
[edit] OnShutdown
This event is triggered when a XApp is terminating. It happens once in the execution-lifetime of your application.
[edit] Browser side XApp – Your Ajax application
Since your application runs mostly inside a web browser, the browser side XApp will be the one you have most contact with, while building your application. There are several very useful properties and events in this class which you can use in your code.
[edit] Events
On the browser side of your application the TXApp class also offers a pair of events.
[edit] OnBeginLoad
This event is triggered every time the browser sends a request to the server, as the request is sent.
[edit] OnEndLoad
This event is triggered every time the browser sends a request to the server, as the request is completed.
The OnBeginLoad and OnEndLoad events would be ideal places for you to, for example, implement the on and off "loading..." message which is generally used in Ajax applications that go through large scale interface transformations. The www.morfik.com website is a good example of this behavior.
[edit] Properties
Just as on the server, on the browser side of your application, the TXApp class offers several properties which might come in handy in different situations.
Forms Property
The Forms property allows you to have access to all the Forms that exist in your application. The code snippet that follows exemplifies a way of accessing these forms. (In this Pascal example we take the Index form from the collection of XApp forms and typecast it to the Index form class).
with Index(xApp.Forms['Index']) do
begin
btnNew.Enabled := False;
btnPrint.Enabled := False;
end;
[edit] Wrapping it up
The Morfik Framework offers not only a wide range of classes, functions and High-level Objects for use by the application developer, but a sophisticated services infrastructure that combines with the class and function library. As you familiarize yourself with these entities and the behavior of the services you should notice your individual productivity climbing.
