Identifying and creating your application pages

In Morfik all applications are composed of one or more pages, not unlike most websites you daily visit on the web. The Pages represent the pages the end user will be able to navigate to inside your application or website and created by assembling together a set of Forms and organizing them appropriately. The organization and navigational structure of the application is defined by how these Pages are assembled and linked together.

Pages define application organization

In a Morfik project Page objects define your application's interface and internal organization as they define the placement of content and navigational structure. The navigational structure is defined by what pages you create and how they are linked together to reach the desired results of your application or website.

Figure 1: Top level navigation structure within a website or web-based application.

In figure 1 you can see the basic structure of an application or website with several first level pages being linked to from the project's Home page. Pages also contribute to the definition of what an application will look as they are responsible for establishing the general layout of the application as well as setting the background over which the application is designed.

Identify your application's 'Pages'

This can be a hard first step when you are new to web development, but it quickly becomes easier with a bit of practice. Many developers coming from a desktop development background have difficulty imagining that an application can be divided into pages, but most can. How do you go about doing that?

Even if you have never, ever, worked on creating a web application, you have been a user of the Web and you can put that experience to use and envision how your application's functionalities should be grouped and how individual bits of data would be presented to the end user.

Think of how your application would change as the user navigates through the options. You can start by establishing what would be the first "page" or "screen" the user would see on entering your application or website. That will be your "home" page. What options will be available for the user on that page and what will the page look like when the user chooses each of these options? A good portion of this page might even remain unchanged when the user selects a specific option. Though you might be changing just a small portion of the page, consider this as another page or a state, and assign it a name.

Once you have thought through the first levels of your application and considered what "pages" you are going to have, you should have most of the material you need to begin mapping it out. Look over your notes and ask yourself if some of the "pages" you have singled out have the same structure but differ in the content they are showing. If the answer is yes, than flag them. These might be candidates for being a single page with different parameters or part of a related set of pages.

Consider the diagram shown below, in Figure 2. Notice that the pages which are linked from the Home page all have names in the plural form. This indicates that they lead to pages that provide information about multiple items of whichever type they are related to. It makes sense that you be presented a list of items to choose from before you can focus on an individual item. If you are dealing with a homogeneous group of items, items which all have the same set of categories, you would want to create a single "page" which can display information about any specific item, instead of having to create a page for each individually.

Figure 2: The application's structure with the addition of parametric pages

This will not only cut down the work necessary to create the application in the first place, it will make it easier to update or change in the future because instead of having a specific page for each of the company's products or customers, you have only one which displays different information based on a parameter it receives.

This process of "mapping" your application can be applied repeatedly until you have a good view of all the pages that you will need to build and which ones can be parametric. Note on the diagram in Figure 3 that pages are organized in a sort of drill down structure, going from the one with a very broad information scope (the home page) to pages which are more specifically focused. This is a common pattern to look for in designing your website or web-based application.

Creating a New Page

When creating a new project you are asked to choose a project template. A project template contains a number of pre-designed page templates that are used during the process of creating a new page. These page templates define the layout of a page and provide empty spaces for content. A new page is created by choosing one of these page templates.

To create a new page simply run the New Page command in the Power Menu (see figure 3) .

Figure 3: Create New Page Command.

Then, you will be promoted to choose a page template. See Figure 4. Enter a name, select a page template and then press OK. Morfik will create and open a new Page document using the selected page template as the basis of the layout of the new page. See Figure 5.

Figure 4: New Page Dialog.

In the screenshot shown in Figure 5 the area that is dimmed displays content that is inherited from the selected page template. The white and green sections with thin blue frames are SubForm controls whose contained forms is to be defined. To define a form click on the little arrow when the Subform is selected and choose the create form command. Alternatively you can double-click on the Subform and a form will be automatically created.

Figure 5: New Page Dialog.

Creating Application-Specific Page Templates

Once you know some or all of the pages you will have in your application the next step is to look for commonalities between them. For example, most websites maintain a common header throughout all pages, providing general navigation options. This could be a commonality between all pages of your application as well. If not, there might be others that you will only be able to determine once you have thought carefully about how your application will work and what information it will display in any given state.

If you have identified groups of pages that share certain characteristics you may choose to create a page class or template to define the set of characteristics that they will share. It is common for a Morfik project, be it for an application or for a website, to have several page classes or templates. These special pages make the work of creating several pages that are similar much easier and faster.

To define an application-specific page template based on an existing page within your project, right-mouse click on the page while in the Project view and then select the properties command. Once the page document properties dialog appears tick the "Defines Page Class" checkbox. See Figure 6. The new page template should appear in the New Page dialog.

Figure 6: Creating Application-Specific Page Templates.

Master Forms

In addition to the ability to define a template page based on an existing page within your project (see above), it is possible to define a page template based on an existing Form. Forms that are used in this way are called Master Forms. In deed, Master Forms provide the base layout for all pages in your application. In these Forms you will define areas, which might be common to a number of pages in your application and others that will always be different from page to page.

To define an application-specific page template based on a Form, right-mouse click on the Form while in the Project view and then select the properties command. Once the Form document properties dialog appears tick the "Defines Page Class" checkbox. See Figure 6. The new page template should appear in the New Page dialog.

Page Templates for Mobile Devices

with Morfik it is possible to create a separate set of pages for users accessing the application through an iPhone, an iPod or an iPad. A Morfik project allows the developer to specify which Page object will function as the home page for each type of device. Through the hyperlinks in that page an entirely separate interface can be provided for each type of device.

Figure 7: A Page designed for an iPhone or iPod Touch.

A single Morfik project can contain different sets of pages for each kind of device: desktop, handheld and tablet. All of these pages may share forms and back-end code in order to minimize the effort required to create multiple applications to handle every type of device.

Figure 8: Default page dialog.

In figure 8 the Default Page dialog is shown with text boxes for the developer to specify what should be the default page for each type of device. Options are available for regular computers, i.e. desktops and notebooks, iPhones and iPods, the iPad and all other mobile devices.

Through this dialog it is possible to set more than one device to have the same default page, if that is compatible with the webite's design and appropriate for providing the necessary functionality to end-users.

Page URLs

Morfik Pages have a URL property which is used to define a relative path for the page. This relative path will compose the page's full URL when combined with your application's root URL. Inside your current project you will be able to reference a page by its relative URL for the purpose of establishing links between pages and defining the navigational organization of the application.

For navigation from outside the application you will always need to use the complete URL for the page.

A URL can be defined by clicking on the URL button in the inspector panel, or selecting the Define URL command on the Ribbon and supplying a path for the URL which is shown in Figure 5.

Figure 5: Dialog for publishing URLs in the Morfik development environmnet.

Since Morfik pages objects are not a reference to actual HTML files this virtual path can be defined in a completely arbitrary way. There is absolutely no requirement that the supplied path should bear any resemblance to the names of the forms that are used in defining the particular state of application for which the URL is being published. Furthermore, the logical hierarchy in the path which is defined through the folder notation can be made up in any imaginable way.

Page URL Parameters

Morfik web development methodology is heavily geared towards using parameters. Parameters are defined for forms and queries when they are created. Subsequently specific values need to be supplied whenever such forms or queries are invoked. This pattern and its requirements do not change with the new model of hyperlinks and Published URLs.

In the new system, parameter definition remains the same so far as forms and queries are concerned. However, there is a need for explicit representation of these parameters within a published URL.

A full URL has many parts including standard parameters that appear after the “?” delimiter as a sequence of name=value pairs separated by “&” in accordance with various web standards. A clean URL on the other hand is a non-technical term that is used to refer to URLs that do not have such parameters. A published URL in Morfik is a clean URL and does not use the notation above for parameter passing. Clean URLs use an implicit way of mapping values that appear in the main body of the URL to the corresponding parameters defined for the URL. This approach is often referred to as URL rewrite and normally is performed at the web server level. In Morfik this process happens within its framework.

Parameter mapping in Morfik occurs at the time that a URL is being published. Segments of a URL can be marked as representing a parameter value through the use of square brackets as shown below:


Given the above definition a given instance of a clean URL such as:

can be mapped to a full URL as shown below:

It is important to note that when publishing a URL no new parameter is being defined. Publishing of a URL only involves the mapping of segments of a URL to parameters that are already defined by the underlying forms. Using the mapping information, parameter values that are present in a clean URL are passed through to all forms that happen to have a parameter defined by the same name.

Mapping Ambiguity

It is important to mention that the process of parameter mapping is not perfect. There may be occasions where it is not possible to perform the mapping due to ambiguous definition of published URLs. Under these circumstances parameter mapping may not produce the expected result. Ambiguity results when two or more published URLs have overlapping paths with parameters that can be interpreted in multiple ways.

An example of this scenario is shown below:[prmFeature][prmCategory]/[prmProductName]   

In the example above the two Published URLs create ambiguity. If the following URL is supplied, both of the above Published URL definitions can be selected by the system to perform the required mapping.   

In the case where the first definition is selected, the mapping would produce the following full URL which is the correct mapping:  

Using the second definition, the mapping would produce the following erroneous full URL:  

To resolve ambiguity Morfik uses the simple formula of selecting the published URL definition whose fixed portion (URL minus parameters) is the greatest in length.

Using the above formula the right result is obtained for the given instance of the supplied URL. However, if the following URL is encountered the wrong definition would be selected. 

The resultant full URL will be:

instead of:

The above scenario highlights the need for careful selection of paths and a valid range of parameter values when defining parameters in a Form or Publishing URLs so as to eliminate potential for ambiguity.

Ambiguity can be totally removed from the above definitions if the first published URL definition was changed to:[prmFeature]   

And that “SoftwareProduct” was never chosen as a label for a product category.

Related Topics

Back to top