How is Morfik different?

If you are familiar or have had any experience with building websites using conventional tools you might find it initially difficult to get your orientation right with Morfik. This however will not last long. Once you are past the initial stage you will imediately realise the power of the new approach.

The following sections aim at helping you to get your bearing right with Morfik by describing key differences between Morfik and other web development tools.

No HTML or CSS files

One of the major differences between Morfik and all other development tools for the creation of Web applications is that Morfik does not force the developer to understand how a browser works. The developer does not need to know how to code HTML, XHTML, CSS, HTTP, SOAP or whatever other acronym that has ever been invented to describe techniques and file formats for web development.

In Morfik you will build user interfaces using objects that represent higher levels of abstraction such as Buttons, Forms, Containers, Labels, DropDowns and Calendar controls instead of HTML tags and their associated styles. Given a high level description of design, through the process of compilation, Morfik generates the necessary HTML, CSS, JavaScript and image files.

When you first try Morfik it is immediately obvious how easy it is to create the basics of a web application, without actually doing any coding. What is more impressive is that not only does it not ask you to write any HTML or scripting code, but it does not spit these out at you.

Building Forms, not Pages

In Morfik you do not write pages, but design Forms. You might ask how can that be, when the Web itself works with Pages? Well, Morfik does work with Pages; It just does not need you to think of them quite that way (most of the time). The main interface metaphor used by Morfik is the Form, as in all major desktop development tools. This is a significant difference because when Web-based software development became Page-centric, to accommodate the way things worked on the Web, it overlooked the point that Web Pages were for delivering text content and not interactive applications. Modern, Ajax enabled, Web applications have few pages, but these pages undergo several changes in appearance in order to interact with the user. With Morfik you design Forms for user interaction and not just content presentation.

Another major difference between Morfik Forms and HTML Pages is that the Forms can be self-containing (both at design time and at run time) and therefore extremely modular. HTML pages are NOT! Though you can use server side to compose a Page from several HTML snippets, you cannot say that you define an HTML Page in terms of other HTML Pages. Due to this characteristic the layout and, more importantly, the behavior of an arbitrarily complex page can be successively reduced down to simpler and simpler Form constructs.

What happened to Pages?

Unlike other web applications that consist of a series of web pages. Morfik uses a single page to run an entire application within the browser. This radical move ensures two key benefits for the Morfik developer and the end user:

1- No page refresh is required while a user interacts with a Morfik application

2- No post-back is needed for tracking state changes within an application

Not refreshing a page makes Morfik applications to behave more like desktopn applications having a greater level of "smoothness". It laso means the state of the application does not need to be constantly posted back to the server every time a page is closed within the browser. Imagine everytime you run a command within a desktop application, the application would save its current state before shutting down and then immediately restarting again! While this may be tolerable for smaller applications, it is clearly impractical to have this model used for larger applications such as word processing or spreadsheet applications. The same is equally true about simple and complex user interfaces on th web.

Having a single page to represent an entire application within the browser is highly desirable form a software development point of view. However, from the Web point of view this model has serious short comings that need to be addressed. The World Wide Web works best with pages and that shows through its basic operations. For example, the hitory list within browsers and the associated back and forward buttons, the common practice of bookmarking, hyertext model and hyperlinking, and search engine bots all assume the existance of web pages with distinct Urls. Morfik applications need to comply with this page-centric view in order to successfully integrated with the rest of the web.

To achieve this Morfik introduces the abstract concept of Virtual Pages. In Morfik the state of an application user interface at any given point in time is considered to be a virtual page. Whenever the state of an application user interface changes in response to user input, the new state is thought of as a new virtual page.

Morfik's virtual pages are abstract entities and as such you do not build them. Instead they are published and made identifiable by defining a URL for them. There are many virtual pages that are not interesting within the space of your application. These pages are not worth identifying and are considered as internal to the application (not visible to the outside world). On the othe hand the virtual pages that are published are extrememly important as they expose interesting points within your application space to the outside world.

Use of absolute coordinate system

One of the things that you will notice as soon as you start working with Morfik is that when you place a button it will go exactly where you point the mouse to at the time of placement. This is because in Morfik you do the layout of user interface in absolute coordinates. This is not extra ordinary by any stretch of imagination, until you realise that this is not the behaviour in other tools!

Any one who has tried using an HTML editor can attest to the awkwardness of the process. This is due to the design of HTML language and the way browsers render them. Browsers work like word processors in that they consider the content fluid and should flow. Style is simply an attribute of the conent which is applied in the form of instructions in a separate document known as a CSS file. While this is suitable for pages that have little functionality and simlpe design, the task becomes progressively difficult as the desgree of the sophistication grows in terms of behaviour and appearance of the application user interface. So much so that most people have decided that a text edtior is the best tool for coding the user interface of modern Web applications.

Morfik uses a unqiue blend of absolute positioning and fluid layout that makes visual design of complex user interfaces not only possible but fun!. This blend allows the designer to do the layout of application user interface in absolute coordinates at design time along with specifications that provide for a reasonable degree of flexibility fo the layout at run time. Of course it is possible in Morfik to mark a specific region in the layout to follow fluid layout rules similar to the conventional approaches. We refer to this model of positioning as Plastic Layout.

For every Form you get two code modules instead of one

One aspect of Morfik that might be difficult to get your head around initially is the fact that In Morfik every form has two associated modules. In Morfik the code associated with application user interface resides both in the browser side as well as the server side of your application. The moldule residing in the browser side implements the Ajax behaviour (red color used for sysntax highlighting) while the one residing on the server side (blue color used for syntax high lighting) has a more conventional role similar to the server centric systems such as PHP or ASP.

Although implicitly connected, these two modules do not directly interact with each other. They simply represent the same user interface elements in two different contexts. One module compiles into binary and runs on the server side weher as the other compiles into JavaScript and runs within the browser.

Graphical Design is merged with Visual Programming

In Morfik you define the behaviour and appearance of your application using the same tool and as part of the same process. Unlike other approaches where graphical design, page layout and coding are considered as separate processes and often done by different people using separate tools (e.g Photoshop for graphic design, Dream Weaver for HTLM layout editing and Some Specialized Text Editor for coding) Morfik offers one tool for all aspects of user interface design and programming.

Morfik drammatically increases the speed of the development of modern web applications by extending its visual programming model to include the graphical deisgn aspects of a web application.

Unlike desktop applications, graphical design is a significant part of Web application development process. Modern Web applications provide enahnced user experiences through graphically rich interfaces that include, amongst other things subttle effects such as rounded corners, sources of light, shadows, reflections, anti-aliased text, etc. Due to the current limitations of browsers, these images need to be broken down into a large number of smaller fragments which in turn need to be meticulously coded into HTML and CSS documents. Any non-trivial change to the user interface layout or style would require rebuiling and recoding of these images.

Morfik removes this burden from you by automating the creation and the subsequent management of these images during the development and at run-time. This opens up new possibilities that are normally extremely difficult to achieve manually. The best example of this is Image Bundling. In order to reduce the number of of round trips made to the server at run time , Morfik bundles multiple images into a single file at design time and subsequently manages the complex partitioning of them at run time. The complexity associated with this task makes it prohibitive to be carried out manually using conventioanl approaches to used for building graphical user interface for the Web.