How is Morfik different

If you are familiar with or have had any experience with building websites using conventional tools, you might find it quite a bit different when working with Morfik. This, however, will not last long. Once you are past the initial stage you will immediately realize the power of the new approach.

The following sections will help you to get your bearing right by describing key differences between Morfik and other web development tools.

No HTML or CSS files

One of the key differences between Morfik and other web development tools is that Morfik does not require the developer to know the inner workings of the browser. The developer does not need to know how to code HTML, XHTML, CSS, HTTP, SOAP or any other acronym that describes techniques and file formats for web development.

In Morfik, you will build user interfaces using objects that represent higher levels of abstraction such as Pages, Forms, Buttons, Containers, Labels, DropDowns and Calendar Controls instead of HTML tags and their associated styles. Through a process of compilation, Morfik generates all the necessary HTML, CSS, JavaScript and image files based on the high level description of design provided by the developer.

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 you don't have to write any HTML or scripting code — and Morfik does not spit these out at you.

Designing Pages

In Morfik you do not write pages, you design them. You also design Forms—a metaphor used in all major desktop development tools. Modern, Ajax-enabled web applications have what might be considered few pages, or in some cases only one, but these pages undergo several changes in appearance in order to interact with the user. With Morfik you will design Pages as you will want your application to display them, by designing and aggregating Forms for user interaction in addition to content presentation.

Forms can also 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 scripts to compose a Page from several HTML snippets, you cannot define an HTML Page in terms of other HTML Pages.

In Morfik, the layout and, more importantly, the behavior of an arbitrarily complex page can be successively reduced down to simpler and simpler Form constructs.

Pages in Morfik

Unlike other web applications that consist of a series of web pages, a Morfik application uses a single page to run an entire application within the browser. This single page will morph itself into all the pages that compose your application, without ever requiring a full page reload by 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 postbacks are needed for tracking state changes within an application.

Avoiding page refreshes makes Morfik applications appear seamless and behave more like desktop applications with a greater level of continuity and smoothness. Also, the state of the application is not posted back to the server every time a user goes to another page within the same application. Imagine if every time you ran 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. The same is equally true about simple and complex user interfaces on the web.

Having a single page to represent an entire application within the browser is highly desirable from a software development point of view; however, from the Web point of view this model has some flaws that need to be addressed. The World Wide Web works best with pages and that shows through its basic operations. For example the history list within browsers and the associated back and forward buttons; the common practice of bookmarking; hypertext models and hyperlinking; and search engine bots all assume the existence of web pages with distinct URLs. Morfik applications need to comply with this page-centric view in order to successfully work with the rest of the web.

To achieve this, Morfik introduces the abstract concept of virtual pages. In Morfik, the state of an application's 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, but are "materialized" in high level objects called Pages. These Page objects represent particular states that the application will assume. From an end user's perspective a Morfik Page object is exactly like any other web page created with any other tool, but internally the Morfik Framework transparently makes it work in a more optimized manner, by morphing the single page Morfik uses to display the entire application.

Pages are are published and made identifiable by defining a URL for them. Your application may define any number of Page objects for internal use which are not relevant to the outside world and are not worth publishing. On the other hand, some pages are extremely important and it is these that you want users to find and be able to directly access.

Read more about Virtual Pages...

Read more about Page objects...

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 the user interface in absolute coordinates. This does not sound particularly extraordinary until you realize that no other web development tool can do this.

Anyone 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 it. Browsers work like word processors in that they consider the content as totally fluid. Style is simply an attribute of the content 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 simple design, the task becomes progressively more difficult as the degree of the sophistication grows in terms of behavior and appearance of the application user interface. Many people have had to resort to a text editor as the best tool for coding the user interface of modern web applications.

Morfik uses a unique 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 interfaces in absolute coordinates at design time, along with specifications that provide for a reasonable degree of flexibility for 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. The code associated with the application user interface resides partly in the browser side and partly on the server side of your application. The module residing in the browser side uses red for syntax highlighting and implements the Ajax behavior. The one residing on the server side uses blue for syntax highlighting and has a more conventional role similar to server-centric systems such as PHP or ASP.

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

Graphical Design is merged with Visual Programming

In Morfik you define the behavior 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—for example Photoshop for graphic design, Dream Weaver for HTLM layout editing and a specialized Text Editor or IDE for coding—Morfik offers one tool for all aspects of user interface design and programming.

Morfik dramatically increases the speed of the development by extending its visual programming model to include the graphical design aspects of a web application.

Unlike desktop applications, graphical design is a significant part of the web application development process. Modern web applications provide enhanced user experiences through graphically rich interfaces that include, amongst other things, subtle effects such as rounded corners, sources of light, shadows, reflections and anti-aliased text. 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 re-building and re-coding of these images.

Morfik removes this burden by automating the creation and the subsequent management of these images during development and at runtime. This opens up new possibilities that are extremely difficult to achieve manually. Take Image Bundling for example. In order to reduce the number of round trips made to the server at runtime, Morfik bundles multiple images into a single file at design time and subsequently manages the complex partitioning of them at runtime. The complexity associated with this task makes it prohibitive to be done manually using conventional web development tools.