Binding data to your application user interface

Morfik embraces a concept called Data Binding, which makes presenting the information in your application's database in a pleasing, functional manner quite simple.

In this article we will provide you with a general overview of how to plan your application's interface based on a database schema you have previously constructed. In this particular case we will see how to plan a generic site interface for the publication of articles, grouped under sections. Our primary objective is to create a simple but flexible application that will allow all of the website’s content to be edited without needing to changing the supporting application or the database structure.

In order to achieve this goal, while maximizing the effectiveness of Morfik and the Morfik Framework, we will see how to use simple but effective queries and small Forms to link everything together into the desired behavior for a website. Throughout this article we will be using the database that was created in the Defining the Data Schema for your application article as the basis for our small CMS application.

Sample projects of the CMS application can be downloaded from this page.


Planning a site's layout

A website's layout is generally associated with its purpose and with the aesthetic sense of the designer in charge of its creation. In this article we will be creating a practical layout which can be applied to a website about almost any topic or subject. We chose to follow a popular layout with a menu of options on the left side, a header with the title at the top and informational content in the largest portion of the page.

Figure 1 shows a schematic diagram of how content is organized in sites which follow this particular pattern.

binding-data-to-interface-layout.png
Figure 1: Schematic Diagram of how content is organized in the example used in this article.


This general layout has been quite popular with websites for many years; while not the most sophisticated of designs, it is very practical. Figure 2 shows our sample application running in the Morfik Debug Browser. Each of the three areas that we have just mentioned can be seen marked with rectangles and identifying numbers.

This particular layout matches very well the information we want to present in our generic website. First there is the name of the website, second there are different topics of interest, grouped into 'sections' in our database model. It stands to reason that if we have topics classified into sections we might want to choose which section's articles we want to see.

Once a layout and design have been settled upon, the next step will be to create a page that matches that concept, bringing together the necessary forms. Once a page has been designed it should have a URL assigned to it. It is this URL that you will use to tie in the different parts of the application. This makes it easy for you later, to change the layout to a totally different one by recombining the Forms in a different manner in a new page, but with the same URL. Figure 2 shows the basic layout that we wish to implement, with the final application running within the Morfik Debug Browser.

binding-data-to-interface-cms-areas-in-chrome.png
Figure 2: CMS project running within the Chrome Browser. Areas that present information
from different data sources are highlighted by red rectangles


To create this layout, data comes from several tables: 'WebsiteInfo', 'Section', 'Article' and 'UserCatalog'.

Information shown in both the header and the footer comes from the 'WebsiteInfo' table. This table always holds only one record with basic information about the website: Title, Subtitle, copyright message, etc. The list of topics or sections that appears to the left of the page comes from the 'Section' table. Titles, summaries of articles and the names of authors' come from three tables: 'Article', 'Section' and 'UserCatalog'.

Creating Pages

The first step in creating the interface for any application, once you have planned its layout, is to create the Pages which will provide the organization and structure of that layout. In the case of the example we are going to be using through out this and other database-related articles we will have two groups of pages, one for the end-users of the application or website and another for data entry and administration.

Most of the end-user facing interface for this small project is implement in just three pages: Start, SectionContent and ViewArticle. These pages provide the home or staring position for the site, aggregation by section and view of the full text of an article, respectively.

The needed pages for this application can be created by using the New Page option on the main menu and selecting the Index template as the base for the new page. The subforms can then be created using the New Form command.

Creating Forms

The second step in creating the interface for any application, once you have planned and created its pages, is to create the Forms which will provide the functionality of those pages. In most cases this will be just the main Form of your application, while in others it might involve two or more Forms. For the example we have chosen we actually need two Forms to provide the main layout functionality for all of the application. Whatever Form is the outermost form in your design will serve as the basis for the creation of the application's default Page.

The frmRoot Form

That starting point for our application will be the frmRoot Form since it provides a layout for the Start page. This Form is used mostly for cosmetic and layout purposes, to help us position the site's content in the middle of the available space and properly distribute it in the positions we want. This Form provides the background of the application's main/home page and defines where other forms will be inserted, effectively bringing together all the interface components in the appropriate layout for displaying the CMS Project's "Home" page.

Morfik projects can be created based on templates with several pages and forms. In this particular case the application was created based on one of the provided templates and trimmed down later to remove any unnecessary items.

In order to reproduce the application shown in this article you will need to slightly alter frmRoot. This Form is used to provide some spacing and a nice looking border around all of the application's content area, by centering the content within the browser window. The main reason for having this Form is that while it can be interesting to have your content stretch horizontally across the users entire screen in some situations, it can also be quite a negative experience for the end user in others. If the user has a physically large monitor with a very high resolution, he can find himself having to move his head in order to read the full extent of every line in a text and that is certainly to be avoided. The CMS application adopts a fixed content width, while allowing the outer most Form, in this case the frmRoot Form to stretch. This presents the user with a content area that is well defined and centered in this monitor as you can see in Figure 3.


binding-data-to-interface-frmroot.png
Figure 3: The frmRoot Form in Design mode within the Morfik development environment.

The Start Page

The actual content layout of the CMS application is created by a combination of the frmRoot and frmLayoutContent Forms, which provide the positioning and sizing of the areas (SubForm controls) that will hold the different parts of the content. These areas are filled in, in the Start page with two forms: The frmArticleContent and the frmSidebar forms.

To layout the content, as seen in Figure 1, we need to have four different areas. Two of these are provided by the native Header and Footer bands of the underlying frmRoot form while the other two occupy different portions of the Details band of the frmLayoutContent Form and are represented by two SubForm controls. In this area, we want to have a list of sections in a small area to one side and a list of articles stretching across the remaining space. During normal navigation of this website, which articles appear on this list will be determined by which section is selected by the user, but the user will be initially shown to selection of the most recent articles, regardless of section.

At any time that the user chooses to see the Home view, the most recent articles will be shown, regardless of which section they belong to. This Home view is implemented in the Start page, which brings together the forms that compose this summary of the most recent articles and the list of sections in the website.

To achieve this layout we need to have properly positioned a pair of SubForm controls in the frmLayoutContent Form. These controls will hold other Forms which will be responsible for presenting the actual content. This same start Form implements the header and footer viewed in the Start page and all throughout the website but defers all other content to Forms which will be inserted into its two SubForm controls, in different Pages. These other Forms will be loaded dynamically when specific Pages are requested from the application. In the right area, the frmSideBar Form will only be replaced by the frmAdminSideBar Form when you enter the site maintenance portion of the application, but on the left side several Forms will alternate as you navigate through the application's Pages, displaying the articles in their different views.

binding-data-to-interface-start-page.png
Figure 4: The Start Page at design time with frmSideBar and frmArticleContent Forms statically bound to it.


The Datasource

To be able to bind controls placed on frmRoot, the datasource for the Form is set to the WebSiteInfo table, allowing any controls placed on the header, footer or detail band to be bound to any of the fields in that table.

The Header

The header for our CMS application's website is identical to the header of the frmRoot Form, marked with the number 1 in Figure 4. It is created using the Header band of the frmRoot Form, which serves as the background for the Content page which is used as a template for most of the pages in this application.

Everything in the header is done using TextLabel, Button and Image controls. The TextLabel controls are associated with certain database elements through data binding. With the frmRoot Form data bound to the WebSiteInfo table, its TextLabel controls are bound to the fields which will provide the information for the website's title and subtitle.

The Footer

The footer for the CMS application's website is again, in a manner similar to the header, identical to the footer for the frmRoot Form, and thus created using that band. In this case the Footer band is used with a TextLabel control which is bound to the field of the WebSiteInfo table which stores the Copyright message to be displayed on the site. In Figure 4, the footer is marked with the number 3.

The frmSideBar Form

The frmSideBar Form is opened into the right SubForm (SideBarArea) of the Start Page (number 2 in figure 4). This form will be responsible for navigation through all the end user accessible content in the website, allowing the user to filter for the content of a specific section or return to the unfiltered view of the site's Home, implemented in the Start page.

Content displayed in the frmSideBar Form is divided through the Header (marked with the number 2 in Figure 5) and Details (marked with the number 1 in Figure 5) bands. In the Header band a single option will be presented to return to the startup content of the home page. In the Details band an option for each of the Subsections of the current Section will be displayed. Note that the options in both the Header and Details bands have been made to look the same and to the end user will appear to be a part of the same options set.

binding-data-to-interface-cms-frmsidebar.png
Figure 5: The frmSideBar Form seen in Design mode within the Morfik development environment.
Note: Red TextLabels indicate ones are not visible at runtime.

The need to actually create the separate options in the Header and Details bands comes from the fact that they will use different base URLs to display the information from different sources. The Header will be referring to a URL that is bound to a set of Forms which always return the most recent entries, regardless of which section they belong to. The option provided by the TextLabel control in the Details band will be referring to a URL which is bound to a different set of Forms which take as a parameter the Id for the section you want to view. Based on this Id, the Query to which one of the Forms is bound will return the most recent articles which belong to that specific Section.

We will see how to create the appropriate Links for each of the TextLabel controls after we have gone through all the Pages and Forms we need to complete our interface.

The frmSideBar Data Source

The frmSideBar Form is bound directly to the Section table, as it will display all the sections available. The Home option that is displayed on the frmSideBar form is a static text entered into the Caption property of a TextLabel control, and thus not read from the data source as all other sections that will be listed.

The frmArticleContent Form

The frmArticleContent Form is shown inside the main content area of the Start page (number 4 in figure 4), and is actually responsible for displaying the titles, authorship and summaries of the most recent articles available, from all sections of the website. Figure 6 shows the frmArticleContent Form in Design mode within the Morfik development environment.

The NavigationBar is necessary in this case because the number of articles in a single section will sometimes be more than would be desired in a single page. In this case, utilize what is commonly known as 'paging'—a technique which allows us to specify how many records will be shown in each 'page'. In order to customize the paging the PageSize of the Form should be set to a number which provides the best result for each specific application. In the case of the CMS application, a general content management application, the default value of 10 was considered adequate. This means that ten records will be presented in each 'page'.


binding-data-to-interface-cms-frmarticlecontent.png
Figure 6: The frmArticleContent Form in Design Mode within the Morfik development environment.


The frmArticleContent Data Source

This Form is responsible displaying the Title and Summary of each article, as well as the author’s full name. Since the Article table does not have the author’s name this Form needs to be connected to a data source which is a query that retrieves data from the Article, UserCatalog and Section tables. In this case the frmArticleContent Form is using the GetArticlesAndSections query as its data source.

This query retrieves all the basic information that might be required from the Article table, plus the article’s author full name from the UserCatalog table and the name of the Section to which it was published from the Section table. This query, as with the one which had been used in the SideBar, takes no parameters as it uses Morfik's built-in ability to sort and group information at the Form level so that the most recent articles are the first to appear.

SELECT ALL
    "Article"."Id",
    "Article"."Title",
    "Article"."Summary",
    "Article"."IsPublished",
    "Article"."DatePublished",
    "Article"."SectionId",
    "UserCatalog"."FullName",
    "Section"."Title" AS "STITLE"
FROM
    (("UserCatalog" INNER JOIN "Article" ON 
    ("UserCatalog"."Id"="Article"."CreatedBy")) 
    INNER JOIN "Section" ON ("Article"."SectionId"="Section"."Id"))
WHERE
    ("Article"."IsPublished" = 1)


Note: The GetArticlesAndSections query used as the data source for the frmArticleContent Form specifies a parameter for filtering the articles which are set as published.


This ensures that the site's Home will always be showing the newest articles. The value we define for the Form's Page Size property is key to setting the number of articles that will be visible when the user first enters the website. If we set the page size to 7, for example, we will get seven articles showing. In order to see more articles the user will need to navigate to the next page of data, which will replace the current seven articles with the next seven, in descending date order.

In order to allow the user to navigate through multiple pages of data you need to enable the navigator in either the Header or Footer bands of the Form. In the case of our example application this has been enabled in the Footer band (number 2 in figure 6).

As with the other Forms, once the frmArticleContent Form is linked to the GetArticlesAndSections query it will automatically provide the data needed to properly generate the Form at run time (number 1 in figure 6), when a user accesses a page that contains it. This automatic retrieval of data is a major benefit of Morfik's data-binding approach as it frees the user from having to worry about how to display the information which is recovered from the application's database.

frmArticleContent makes each article title into a hyperlink which, when clicked, will result in a new page being opened with the full set of data for that particular article. While the application will be navigating to an entirely different page, the Morfik Framework will identify that the new page shares several elements with the previsous one and only reload the necessary parts of the content already in the browser. The actual substitution will be of the frmArticleContent form inside the MainArea SubForm control of the frmLayoutContent Form by another Form called frmViewOneArticle. This is achieved by setting the Link property of the ArticleTitleLabel TextLabel control by clicking on the Link button in the Home tab of the Ribbon, when the control is selected.

Notice that no code is necessary to display the full text of the article. Simply setting the Link property of the TextLabel control that displays the title to reference the url defined for showing the contents of an individual article is all that is required.

The Section Page

The actual content layout of the CMS application as we have seen is created by a combination of the frmRoot and frmLayoutContent Forms, which provide the positioning and sizing of the areas (SubForm controls) that will hold the different parts of the content. These areas are filled in, in the Section page with two forms: The frmArticleContentFromSection and the frmSidebar forms.

The frmArticleContentFromSection Form

This Form is actually very similar to the frmArticleContent Form that is part of the Start page as it displays almost exactly the same information, but filtered to reflect the contents of a single, specific, section of the site. Figure 7 shows the frmArticleContentFromSection Form in Design mode within the Morfik development environment.

binding-data-to-interface-articlecontentfromsection-in-ide.png
Figure 7: The frmArticleContentFromSection Form in design mode within the Morfik development environment.


The frmArticleContentFromSection Form uses Morfik’s Grouping and Sorting feature to create a Group Header. In this special Header it displays the name of the Section that has been selected to be viewed in a properly formatted TextLabel control.

The frmArticleContentFromSection Data Source

The frmArticleContentFromSection Form has its data source defined as the GetArticlesFromSingleSection query. This query retrieves all the necessary records from the single section specified as its parameter.


SELECT ALL
    "Article"."Id",
    "Article"."Title",
    "Article"."Summary",
    "Article"."IsPublished",
    "Article"."DatePublished",
    "Article"."SectionId",
    "UserCatalog"."FullName",
    "Section"."Title" AS "STITLE"
FROM
    (("UserCatalog" INNER JOIN "Article" ON ("UserCatalog"."Id"="Article"."CreatedBy")) INNER JOIN "Section" 
    ON ("Article"."SectionId"="Section"."Id"))
WHERE
    ("Article"."IsPublished" = 1) AND ("Section"."Id" = :"PARAMSECTION")

The ViewOneArticle Page

The actual content layout of the CMS application, as we have seen in other parts of this article, is created by a combination of the frmRoot and frmLayoutContent Forms, which provide the positioning and sizing of the areas (SubForm controls) that will hold the different parts of the content. These areas are filled in, in the ViewOneArticle page with two forms: The frmViewOneArticle and the frmSidebar forms.

The frmViewOneArticle Form

Once the visitor to the application's website clicks on a specific article, a complete version of the body of the article must be displayed. To create this view, we need a new Form with the appropriately laid out controls. In this example, this will be the frmViewOneArticle Form. This Form replaces either the frmArticleContent or frmArticleContentFromSection Form within the main content area of the ViewOneArticle page, thus taking the user from a multiple summary to a view with the complete text of the selected article.

Figure 8 shows the frmViewOneArticle Form. Notice that this Form also contains a Footer band. In this case a small link is used to return to the previous view with the frmSectionContent Form exhibiting the articles of a single section.


binding-data-to-interface-cms-frmviewonearticle-ide.png
Figure 8: The frmViewOneArticle Form in Design mode within the Morfik development environment.


Figure 9 shows the website in Google's Chrome browser, with the frmViewOneArticle Form being shown in the MainArea SubForm of the frmLayoutContent Form as a result of navigating to the ViewOneArticle page. The frmLayoutContent form takes up all of the Details band of frmRoot form and divides it into two content areas, one being used to arrange the content into place in the pages that are derived from it.


binding-data-to-interface-frmviewonearticle-in-chrome.png
Figure 9: View of the CMS application displaying the full contents of the Body field, within Google's Chrome Browser.


The frmViewOneArticle Data Source

The frmViewOneArticle Form uses the GetOneArticle query as its data source. This query retrieves all data from the one specific record in the Article table. The following snippet shows the SQL language code for this query.

SELECT ALL
    "Article"."Id", 
    "Article"."Title", 
    "Article"."Body", 
    "Article"."DateCreated", 
    "Article"."DatePublished", 
    "Article"."CreatedBy", 
    "Article"."Summary", 
    "Article"."IsPublished", 
    "Article"."SectionId"
FROM
    "Article"
WHERE
    "Article"."Id" = :"ParamId"

Notice that this is a very simple and straightforward query which will always return a single record from the Article table.

Note: Even though the frmViewOneArticle Form will only display one record, it should be configured to be a continuous form. This is a requirement of the Morfik Framework in order for Parametric Page Links, which are covered later in this article, to work properly. In this case, the frmViewOneArticle Form has a dynamic link which takes the user back to the summary view of the section in which the article is published as well as one that takes the user to the home page.


The First Step to Editing Data

A closer examination of the picture in Figure 10 will reveal a small pencil icon and the word "Edit" by the title of the article. This can be used to alter the information in that specific article.

Figure 10 highlights this small detail to make it easier to notice.

binding-data-to-interface-cms-frmviewonearticle-button-highlight.png
Figure 10 The ViewOneArticle Form in design mode within the Morfik development environment. The Edit button is highlighted.


Clicking on this link will result in an error message, unless the site's visitor has previously signed in by clicking on the Site Management link at bottom the of the page. We will see more information about the login process in another topic of this documentation.

The following snippet contains the full source code of the OnClick event associated with the TextLabel control which is used to represent the "Edit" link.

FX Code

Procedure ViewOneArticle.EditRecordOptionClick(Event: TDOMEvent);
Begin
   If not UserIsAuthenticated Then
     ShowMessage('Operation not allowed.  Please, sign in first.')
   Else
   Begin
     ArticleIDLabel.BandIndex := GetEventSource(Event).BandIndex;
     OpenForm('EditOneArticle', 'POPUP', '"ParamId='
              +ArticleIdLabel.Caption+'", "title=Edit Article",
              "modal=true"');
   End;
End;


Note that the OpenForm command in this case is a bit different than you might have seen in other references in that it specifically requests the display of a Form as a popup "window". The Title parameter for the form will be used as the title of the "popup window" and the modal=true parameter will shade everything else in the browser, limiting user interaction to the new Form.

Page URLs

When you create a Page object in Morfik you will need to assign it a URL string, through the URL property in the property window. It is this URL that you will use throughout the application or from outside it to invoke that particular page. The term URL, within the context of a Morfik application, has a dual meaning. It can refer to an outside web address to which you want to create a hyperlink or can be a reference to an application "Page" object.

In this article we will focus on the second meaning: a reference to a "Page" object defined within our application. Once Pages are created and their URLs are defined in your application you will be able to visually associate Hyperlink properties of controls to them and use the OpenPage function to invoke them through code, if ever necessary.


Parametric Pages

When you are defining Pages you will quickly find circumstances in which you won't be able to achieve the results you want by simply creating a link to a certain set of Forms. You need to be able to pass on information about which records to display, for example. That is exactly what Parametric Pages (Pages with parameters) are for.

Once you have created a Page you can customize it through the Page Parameters dialog, displayed when you click Parameters button on the Home tab of the Ribbon, when in the Page designer. This dialog is shown in Figure 11. The parameters available for selection are obtained from the parameters of the subforms contained in the page. The parameter names for the page are matched by their order to the parameters passed within the URL are are not matched by name. Any parameters passed to the page are in turn passed to the subforms of that page that contain those parameters. For example the parameter PARAMSECTION passed to the page Section (see below) will in turn be passed to the form frmArticleContentFromSection which will insert it into the paramatized query for that subform.


binding-data-to-interface-page-parameters.png
Figure 11: Page Parameters dialog in the Morfik development environment

URLs for the CMS Application Pages

In the sample application used in this article several Pages were necessary in order to implement the desired functionality. The following are the URLs set up for these pages:

  • Home—The start-up page of the website/application. This is the page with a list of the most recently published articles, regardless of which section they have been published to.
  • Section—This is the page with a list of the latest articles published in that specific section.
  • ViewArticle—This is the page with the full text of a specific article.
  • AdminHome—This is the home page for the site management portion of the application.
  • EditSections—This is the page for manipulating data about the sections of the website.
  • EditArticles—This is the page for managing the articles published on the website.
  • EditSiteInformation—This is the page for editing the title, subtitle and copyright string for the website.
  • EditUsers—This is the page for managing the users who have access to the Admin page of the website.
  • ManageLog—This is the page with options for cleaning up the applications sign in log.

Setting up hyperlinks

Once you have published the URLs that define the 'pages' of your application you can start to assign them to the Hyperlink property of controls, where appropriate. In order to do this, you should select the control to which you want to assign a link/URL and click on the Link button of the URLs section of the Home tab of the Ribbon when in the form designer.

This will bring up the dialog you can see in Figure 12, where you can select the URL from a drop-down list of all the URLs that are defined in the application.


binding-data-to-interface-edit-hyperlinks.png
Figure 12: Dialog for selecting or entering the URL which you want to assign to the selected control.


In the dialog which is shown in figure 12 you can also enter an external URL or a mailto link. This allows you to create links to content in other sites and links to email addresses.

You can assign URLs either published by the application or external ones to TextLabels, Buttons or Image controls in order to implement the navigation within your application.

There are two sub-properties that can be set for the Hyperlink property: Target and Title. These properties allow you to have a more fine-grained level of control of how the hyperlink behaves and is interpreted by search engines.

Target - This sub-property allows you to choose one of four options for how the browser will open the hyperlink: _blank, _self, _top, _parent.


Title - While the actual text that will appear on the screen is given by the caption of whatever control for whom the Link is being set, the Title property is looked at by search engines to evaluate the relevancy of the link.

Search Engines

The pages created and linked together through the visual designer in Morfik generate standard HTML and CSS code which can be easily crawled and parsed by search engines. This means that in addition to making it much easier to create the navigation structure of your application and assembling its component Forms, Morfik makes it possible for the contents of your application's 'pages' to be indexed by search engines, despite the omnipresent usage of Javascript and Ajax.

CMS Application Links

In the case of our sample application we need to fill in the links in the side bar and the article headers to provide the basic functionality the application requires. There are a few other links we will have to assign such as the ones that allow us to return from the 'page' in which we see the full text of an article to the site home or to a section home.

  • frmSideBar - In order to replicate the functionality of our sample application you should assign the link for the Home label in the SideBar Form to the "Home" URL. The Section Textlabel control should have its link assigned as section/[$SectionId]. This instructs Morfik to dynamically create a URL which passes as a parameter to the Section "page" the id of the desired section.
  • frmArticleContent - In the frmArticleContent Form the TextLabel control for displaying the article's title should have its Hyperlink property configured to: ViewArticle/[$Id]. This can be achieved by editing the Hyperlink property in the property list for the control or by clicking in the Link button in the Home tab of the ribbon.
  • frmArticleContentFromSingleSection - The frmArticleContentFromSingleSection Form is almost a duplicate of the frmArticleContent Form, using a different data source. It has the same Hyperlink property settings as that Form.
  • frmViewOneArticle - The ViewOneArticle Form has two TextLabel controls near its footer, each of which have their Hyperlink properties set to take the user to a different article list. One TextLabel has a link to the website's home page and the other is set to take the user to the list of articles published in the same section as the one that is currently being displayed by the Form (Section/[$SectionId]). The frmViewOneArticle Form has another TextLabel that works as a hyperlink but does not make use of the hyperlink property. This control handles the OnClick event and uses the OpenForm function to display a popup Form for editing the information of the article currently being displayed.
  • frmAdminSideBar - The frmAdminSideBar Form uses statically defined hyperlinks to allow the user to navigate through the different pages available in the site management portion of the application. Each of the buttons in the frmAdminSideBar Form has its hyperlink property set to one of the following Page URLs which are defined for the navigation within site management pages:
  • EditSections
  • EditArticles
  • EditSiteInformation
  • EditUsers
  • ManageLog

Wrapping it up

Creating the interface for an application which is totally database driven is not a difficult task with Morfik. It is actually quite a simple task, providing that adequate thought and planning has gone into creating a good database schema.

It is actually possible to create quite sophisticated applications while writing very little in the way of code. Most of the work can easily be done through the Visual Designers and through the use of data binding, page URLs and Hyperlinks as shown in this article.

Related Topics

See Also

Back to top