Using Forms to build your application user interface

Both the Morfik Framework and the development environment are designed to make it easy for the user to decompose the problem of creating a web interface into small and easily manageable parts. This is accomplished through the use of pages that are assembled from Forms.

In order to create a good-looking and efficient interface for your web-based application you need to figure out the best way to break down your interface into small Forms and put them together as parts of Pages. You also need to decide how and where you will be using the Form's bands to display relevant data or achieve desired graphic results. There are two major factors that will influence your decision: Data Sources and Appearance.

basic-application-layout-1.png
Figure 1 A Page designed by using bands and composing several forms through the use of SubForm controls.


Breaking up your design into Forms

In Morfik, each Form has one data source and while at first this can seem a little limiting, in does in fact allow you to draw information from many tables using a query. You can also bring data into your Forms using the Repeater control which offers a subset of the form's functionality and is useful to display small list of related data within a form. These elements make the displaying of information from multiple tables pretty straightforward, leaving the work of assembling all the data into a single data set to the database objects of your application.

The diagram in Figure 2 shows a Page that is divided into five different areas, two of them represented by a its native Header and Footer bands and three others represented by three SubForm controls and marked as: Side Bar, Featured Items and Content.

using-forms-to-build-interface-subforms.png
Figure 2: The areas highlighted in red indicate where SubForm controls are used to break up the Page into smaller areas, each of which can be designed as a separate form.


The difference between the layouts shown in Figures 1 and 2, for example, are related to the desire to have content that is considered special in some way appear at the very top. The natural way to implement such a scenario in Morfik is to use a SubForm control and embed a form which recovers and displays the required information in that particular position. The decision to embed a form in a particular position is generally more closely related to either aesthetic or data retrieval reasons, but in cases such as this both play a very important role.

The form to be embedded at the Featured Items region will apply some sort of filter on the whole body of content to determine which items are to be featured. Because these items are supposed to be worthy of special attention, the design should be different enough from the rest of the page to draw attention. In the layout shown in Figure 2, the Featured Items section runs horizontally across the top of the area generally occupied by content. This would might be a good opportunity to employ a continuous form with columns, such as that employed in the home of Morfik's BookCollector sample project.

This case highlights both major reasons why you would make a section of your "page" or outermost form into an embedded form: Selecting a new data source, and having data shown in a special design such as in columns.

Note: If you have forms with such layouts in previous projects that you have worked on, you can copy such forms between projects using regular copy and paste commands.

Design choices based on data sources

While all bands of a Form share the same data source, they are not restricted to displaying the same information. In fact, if you decide to group your data through usage of the Grouping and Sorting option of the Form Designer, you will be given the opportunity to create new bands in your Form in order to display information related to each individual grouping.

The Morfik development environment allows you to specify up to ten fields by which you can group and sort the data that will be displayed in a Form. The Morfik Framework automatically uses this information and adds the appropriate clauses to the SQL commands for the data source in order to recover the desired data. This greatly simplifies the task of creating queries and allows you to choose different forms of presenting a data set, without having to create multiple query objects.

using-forms-to-build-interface-group-header-band-recover-info.png
Figure 3: The Form Band that can be seen at the top, with the text STITLE is
what is known s a group header. This kind of header is added to the Form whenever
you choose while creating a grouping or sorting option.


In the case of the form displayed in Figure 3, we wanted to have the title for a section of articles to be displayed above their summaries. We could not, however, use the regular header to do so, because the form must be a continuous form in order to display the titles and summaries for all articles. This precludes us from binding controls in the header to data fields as there would be no way to specify which of the records would be the source of the displayed information. To work around this we create a Group Header which will take the name of the field by which data is to be grouped. In such a group, all records will have the same value for that specific field and therefore it can be used in that particular header.

using-forms-to-build-interface-group-header-name.png
Figure 4: Same form that appears in the previous figure with the Group Header extended to show its name.


Handling Master-Detail Relationships

There are times, however, when you have a situation referred to as a Master-Detail Relationship between datasets. It is very simple to handle these situations with Morfik, though it might not be immediately evident to a new user.

Morfik makes it quite easy to implement Master-Detail Relationships through the use of dynamic or parametric URLs. By linking to a parametric URL and passing it a different parameter you can display different data sets from the detail data source.

When working with continuous forms you can assign to certain controls links with field references embedded. The field values for the specific records will get added to the URLs at runtime and will effectively become parameters for URLs that were defined as having them. This feature makes it easy to have a SubForm control which loads different data sets based on a value of a field in another data set.

As of Morfik 3.x you can also use the Repeater control to implement the display of a set of records. Depending on the situation this option can help to simplify the application's overall composition by helping cut down the number of small forms required to create each page. This control will also offer a performance advantage in comparison to the use of a form as its implementation requires less round trips to the server for all the data to in place.

Displaying lists

Morfik forms have a view mode which is specifically designed for displaying lists of items. In this mode, which is set by choosing vmContinuous in the View Mode property of the form, all controls inserted into the Details band will be repeated once for each record in a data page. These records will be retrieved from the forms data source and the exact number of records will be defined by the MaxPageSize form property. Read more...

Continuous forms are ideally suited to presenting any and all kinds of lists to users. These can go from having the plain appearance similar to a sophisticated ListBox control from to very complex lists with varied control types for displaying different kinds of information or even recursively embedded lists to provide a view into a hierarchical data structure.

using-forms-to-build-interface-form-as-list.png
Figure 5: This form is used to provide a simple list of records in a table, one line/row for each record.


The form that is shown in Figure 5, above, is intended to display information about an article or document being published on a website. Notice how different bits of information about the article are arranged around the form to provide clear and immediate access to everything a user might need to decide to go ahead and read an article in full. This form does not follow the mold of a plain list, but arranges information in multiple lines using up more vertical space in order to provide the application's user with a more meaningful sample of the articles.

using-forms-to-build-interface-form-complex-layout.png
Figure 6: This form is used to provide a structured view of information about articles. The information is arranged in four lines/rows of controls, but the bottom TextLabel control will expand to multiple lines if the data so requires.


Design choices based on appearance

When designing your application's interface, there are choices that are dictated solely based on aesthetic considerations. For example, in some situations you will want to use the Header band to highlight titles for sections of a virtual page with different formatting from that of the Detail band. In this case, even though bands are generally related to how you use and display information from your data source, they become a handy design feature.

In fact, it is sometimes easier for you to envisage how your application will be divided up into Forms, based on how it will look. Once you know how your application should look to the end user, the data sources for each part start to become almost obvious.

If you are building a corporate website or an internal system, there is no need to dynamically compose your header from a database. You already know the name of your company, you already have its logo. In most of these cases the best thing is to go ahead and just create a header with the information you want to display at design time. This will, actually, provide you with an exact picture of how your application will look, right in the form designer.

Website footers are used most often as an area in which to place a series of links and information which, though not part of the core functionality of the application or website, should be available to the end user. This generally includes links to contact pages, copyright information, privacy statements, etc.


Foregoing a Header Band

While a form's Header band offers a convenient way to implement a header or top banner for websites, it does not allow any content to bleed into the neighboring band. This is actually a characteristic of all form bands and is at times a good reason to implement a header at the top of your form's Detail band, instead of using the Header band.

From a strictly visual point of view you can achieve the same results with rectangles and containers as you would with formatting the Header band itself, but you will be able to position controls which seem to crossover one section to the other just by being at a "shallower" z-order level than the controls implementing the header.

using-forms-to-build-interface-image-over-header.png
Figure 7: This page's design creates the website header within the Details band of the current form. Notice the image bleeds across the "boundaries" of the "header" and into the content area.


In the picture you see in Figure 7 there is an image that crosses into the area that can be considered to be the Header that is going to be displayed in the application. This is only possible because the form is not making use of the actual Header band.

Placing controls that are not intended as content, but as a header, inside the Details band of your form or page can indicate the need to include one or more SubForms in the same band for displaying actual content, as more often then not it will come from the retrieval of records in a database.

Foregoing a Footer Band

The same way you can leave out of your design the presence of a Header band, you can leave out the Footer band. You can use controls inside the form's detail band to effectively present the users of your application or website with the contents of a page footer without using the native band. This is however a scenario that is far less likely to occur as the footer is rarely an important component of your overall design, especially since in most cases it is only visible after you have scrolled to the bottom of the page.

Should you believe you have reason for not using the native Footer band of a Morfik form you can use the Vertical Placement property of a control to make it "stick" to the bottom of the form as it grows as appropriate for its content. This will allow you to create a footer that is always displayed at the very bottom of the page, regardless of how long the page is.


Related Topics


Back to top