Binding data to your application user interface

From Morfik Wiki

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.

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.

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.

The new features of defining URLs, which were introduced in Morfik as of version 2.x ,make it quite simple to create a 'page' definition that combines several forms in a layout. You can later, if you wish, change the layout to a totally different one by recombining the Forms in a different manner, 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.

Figure 2: CMS project running within the Morfik Debug 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 the header and 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 Forms

The first step in creating the interface for any application, once you have planned its layout, is to create the Forms which will provide the functionality of that layout. 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 SiteFrame Form

That starting point for our application will be the SiteFrame Form. This Form is used mostly for cosmetic purposes, to help us get a nice shadow around our site's actual content and to position this content in the middle of the available space. This Form will essentially hold in place another Form, called Index, which will effectively bring together all the interface components in the appropriate layout for displaying the CMS Project's "Home" page.

Morfik projects can be created based on a template with three forms: About', Content and Index or totally empty depending on your first option in the New Project Wizard. By choosing a Blank Project you start out with a totally empty project.

We will not be using these initial Forms as part of our application, So you can create a blank project or simply delete them. We will have a Form called Index in the application but it will have a different set of controls on it so you you can either delete the Form entirely or exclude all the controls on the Form.

In order to reproduce the application shown in this article you will need to create a Form called SiteFrame. This Form is used to provide some spacing and a nice looking border with shadow around all of the application's content area. 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 bad 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 SiteFrame 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.

Figure 3: The SiteFrame Form in Design mode within the Morfik development environment.

The Index Form

The actual content layout of the CMS application is created by the Index Form, which fills in the container that provides the border, shadow and positioning within the SiteFrame Form. To layout the content, as seen in Figure 1, we need to have four different areas. Two of these are provided by the Index Form's native Header and Footer bands while the other two occupy different portions of the Details band 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. The articles appearing on this list will be determined by which section is selected by the user. If the user chooses to see the Home view, the most recent articles will be shown—regardless of which section they belong to.

To achieve this layout we need to position a pair of SubForm controls in the newly created Index Form. These controls will hold other Forms which will be responsible for presenting the actual content.

This Form implements the header and footer of the website but defers all other content to Forms which will be inserted into its two SubForm controls. These other Forms will be loaded dynamically when specific URLs are requested from the application. In the left area, the SideBar Form will only be replaced by the AdminSideBar Form when you enter the site maintenance portion of the application, but on the right side several Forms will alternate as you navigate through the application, displaying the articles in their different views.

Figure 4: Index Form at design time with SideBar and ArticleContentFromSection Forms statically bound to it.

The Header

The header for our CMS application's website is identical to the header of the Index Form, marked with the number 1 in Figure 4. It is created using the Header band of the Index Form. In order to get the blue to white gradient effect behind the whole header, the gradient effect applied to the Header band itself. While not easy to perceive in the screenshot in Figure 4, due to the Form band boundaries, there is a thin orange rectangle which is used to create a sort of separator line between the bands.

Everything else in the header is done using TextLabel controls which are associated with certain database elements through data binding. As the Index Form is 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 similar manner as the header, identical to the footer for the Index 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 SideBar Form

The SideBar Form is opened into the left SubForm (SideBarArea) of the Index Form. 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.

Content displayed in the SideBar Form is divided through the Header (marked with the number 1 in Figure 5) and Details (marked with the number 2 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.

Figure 5: The SideBar Form seen in Design mode within the Morfik development environment.

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 Forms we need to complete our interface, and have published the necessary URLs.

The SideBar Data Source

The SideBar Form is bound directly to the Section table, as it will display all the sections available.

Observe in Figure 6 that in the criteria row of the IsPublic field the value of 1 has been entered. The literal value 1 is understood as a constant which will always apply as a filter condition for the IsPublic field. The value of 1 in the IsPublic field means that we only want records which have been marked as Public.

When the SideBar Form is loaded and the ParamParent is part of the parameter string received, it requests the execution of the Query with the corresponding parameter value.

The ArticleContent Form

The ArticleContent Form is shown inside the Details band of the Index Form 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 ArticleContent 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, we result to what is commonly know 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'.

Figure 6: The 'ArticleContent Form in Design Mode within the Morfik development environment.

The ArticleContent 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 ArticleContent Form is using the GetArticlesAndSections query as its data source.

This query recovers 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)

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.

As with the other Forms, once the ArticleContent Form is linked to the GetArticlesAndSections query it will automatically provide the data needed to properly generate the Form at run time, 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.

ArticleContent makes each article title into a hyperlink which, when clicked, will result in the substitution of itself inside the MainArea SubForm control of the Index Form by another Form called ViewOneArticle. 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 ArticleContentFromSection Form

This Form is actually very similar to the ArticleContent Form 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 ArticleContentFromSection Form in Design mode within the Morfik development environment.

Figure 7: The ArticleContentFromSection Form in design mode within the Morfik development environment.

The ArticleContentFromSection 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 ArticleContentFromSection Data Source

The ArticleContentFromSection Form has its data source defined as the GetArticlesFromSingleSection query. This query recovers 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 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 ViewOneArticle Form. This Form replaces either the ArticleContent or ArticleContentFromSection Form within the MainArea SubForm of the Index Form, thus taking the user from a multiple summary to a view with the complete text of the selected article.

Figure 10 shows the ViewOneArticle 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 SectionContent Form exhibiting the articles of a single section.

Figure 10: The ViewOneArticle Form in Design mode within the Morfik development environment.

Figure 11 shows the website in Apple's Safari browser, with the ViewOneArticle Form being shown in the MainArea SubForm of the Index Form.

Figure 11: View of the CMS application displaying the full contents of the Body field, within Apple's Safari Browser.

The ViewOneArticle Data Source

The ViewOneArticle Form uses the GetOneArticle query as its data source. This query recovers 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.

A closer examination of the picture in Figure 12 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 12 highlights this small detail to make it easier to notice.

Figure 12 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 Sign In link at the top 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.

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;

Published Message Sub EditRecordOptionClick(Event As TDOMEvent)
     If Not UserIsAuthenticated Then
          ShowMessage("Operation not allowed.  Please, sign in first.")
     Else
          ArticleIdLabel.BandIndex = GetEventSource(Event).BandIndex
          OpenForm("EditOneArticle", "POPUP", """ParamId=" + ArticleIdLabel.Caption + """,
                          ""title=Edit Article"", ""modal=true""")
     End If
End Sub

published message void EditRecordOptionClick(TDOMEvent Event)
{
     if (!UserIsAuthenticated)
         ShowMessage("Operation not allowed.  Please, sign in first.");
     else
     {
          ArticleIdLabel.BandIndex = GetEventSource(Event).BandIndex;
          OpenForm("EditOneArticle", "POPUP", "\"ParamId=" + ArticleIdLabel.Caption + 
                          "\", \"title=Edit Article\", \"modal=true\"");
     }
}

Note that the OpenForm command in this case is a bit different from what has been used elsewhere in this example. The first difference is that the target is not any specific SubForm but the word "Popup". This is understood by the Morfik Framework as a command to display the 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.

Publishing URLs

Once we have created our Forms, the first step we need to take to start sewing together our application is to publish a set of URLs. 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 an application "Page" definition.

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

Figure 13: Index Form with highlighted SubForm Controls in design mode.

Figure 13 shows the Index Form with the areas occupied by its two SubForm controls highlighted. Each SubForm should be bound to a specific Form by choosing the desired Form's name from the drop-down list displayed in the Form property of the SubForm control. Once all SubForm controls are bound to the desired Form, bring up the Publish URL dialog by choosing the Publish URLoption from the drop-down menu that is displayed when you click on the URL button from the Home tab of the Ribbon in the Form designer.

Figure 14: Dialog for publishing a URL in the Morfik development environment.

Dynamic URLs

When you are defining URLs 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 dynamic URLs or simply URLs with parameters are for.

Once you have published a URL you can customize it through the Manage URLs dialog, displayed when you click on Manager URLs in the drop down menu from the URLs button on the Home tab of the Ribbon, when in the Form designer. This dialog is shown in Figure 15.

Figure 15: Manage URLs dialog in the Morfik development environment

In the Manage URLs dialog, when you add a string in the format [$FieldName] to a URL string you are telling the Morfik Framework that you want the value of that Field (converted into a string, if necessary) to be added to the URL, at that position. This allows you to use information that has been revered by the Form you are creating the link from to specify what content you want to see come up in the set of Forms which your URL represents.

CMS Application URLs

In the sample application used in this article several URLs were necessary in order to implement the desired functionality:

• Home—The start-up page of the website/application. This URL brings up a list of the most recently published articles, regardless of which section they have been published to.
• Section—This URL brings up a list of the latest articles published in that specific section.
• ViewArticle—This URL brings up the full text of a specific article.
• AdminHome—This URL takes the user in the site management portion of the application.
• EditSections—This URL brings up the page for manipulating data about the sections of the website.
• EditArticles—This URL brings up the page for managing the articles published on the website.
• EditSiteInformation—This URL brings up the page for editing the title, subtitle and copyright string for the website.
• EditUsers—This URL brings up the page for managing the users who have access to the Admin page of the website.
• ManageLog—This URL brings up a 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 Link property of controls, where appropriate. In order to do this, you should select the control to which you want to assign a link 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 16, where you can select the URL from a drop-down list of all the URLs that are defined in the application.

Figure 16: Dialog for selecting or entering the URL which you want to assign to the selected control.

In the dialog which is shown in figure 16 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.

Search Engines

The usage of published URLs and Hyperlinks have a side effect; in addition to making it much easier to create the navigation structure of your application and assembling its component Forms, it makes it possible for the contents of your application's 'pages' to be indexed by search engines.

CMS Application Links

In the case of our sample application we need to fill in the links in the SideBar 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.

SideBar

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.

ArticleContent

The ArticleContent Form the TextLabel control for displaying the article's title should have its Hyperlink property configured to: ViewArticle/[$Id]. yViewArticle/[$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.

ArticleContentFromSingleSection

The ArticleContentFromSingleSection Form is almost a duplicate of the ArticleContent Form, using a different data source. It has the same Hyperlink property settings as that Form.

ViewOneArticle

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 ViewOneArticle Form has another TextLabel that works as a hyperlink but does not make use of the hyperlink property. This control uses handles the OnClick event and uses the OpenForm function to display a popup Form for editing the information of the article currently being displayed.

AdminSideBar

The AdminSideBar 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 AdminSideBar Form has its hyperlink property set to one of the following 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, URLs and Hyperlinks as shown in this article.

Related Topics

• How is data managed in my application?
• Defining data schema for your application
• Adding data editing and search functionality to your application
• Writing code for data manipulation
• Built-in Database SQL Statements - Quick Reference

See Also

• Virtual Pages
• Manage URLs Dialog
• Publish URLs Dialog
• HyperLink Dialog