The selected file /tmp/file0lzie9 could not be uploaded, because the destination sites/default/files/css/css_a91cd284035e73ba34d112bfed2f5a16.css is not properly configured.
  The selected file /tmp/fileX30iJE could not be uploaded, because the destination sites/default/files/css/css_de1aa27776f1462d2b0d83a80ce4b92d.css is not properly configured.

In this lesson, we'll introduce you to the concept of context and explain its crucial role in allowing you build complex interfaces, navigation, and automation.

• The Data Layer - Items and Relationships
• The Presentation Layer - Layouts and Fields
• The Logic Layer - Actions

After completing this course, you should be able to answer these questions:

1. What is context?
2. Why is context important?
3. By default, where does a building block get its context?
4. Can a block pass its context to another block?
5. Can you change context?
6. Why would you want to change context?
7. Are there Building Blocks that exist to change context?

Put simply, context is the Interface and Logic Layers' understanding of the Data Layer. In WorkXpress terms, context is the knowledge held by a particular Layout, Field, or Action about the specific Item(s) or Relationship(s) it is about at any given point in time.

The general meaning of the term context is “that which surrounds and gives meaning to a particular thing.” In WorkXpress, context is an extremely important concept to understand when building applications because it enables your Fields to display data. It is not enough for a Field to know what Layout it is in, a Field must also know at any given time what Item to display data about.

In WorkXpress, the context of any Field, Layout or Action tells that Field, Layout or Action what specific Item(s) it should operate on. In other words, it answers the question, for that block, “what am I about?”

Example – context of a Layout: Below we have an empty page that was built to display information about a Contact. It is unable to display any values, because it doesn't know which contact it is supposed to be about. In other words, it has no “context”.

Exactly “which” contact the above page displays data for depends on the context given to it. Context is the Item(s) or Relationship(s) this page will display data about.

The same page layout above has now been given context with the result shown below. It is now about Bob Smith. That is, Bob Smith is the context of the page layout below. Notice the difference between the schematic below and the schematic above. That difference is the result of supplying context to a WorkXpress building block:

In our next example, the exact same page has been given a new and different context. Now, its context is Nancy Jones. This page is now about Nancy Jones.)

Layouts are not the only things that require context to function normally. Most Fields and Actions also must have a context if they are to display or act on data from the data layer (Items or Relationships). Without context, they cannot display data.

Below, we have an empty Field. This Field is “First Name”, and is found on a page about a Contact; the three images shown above, for example. Because it has no context, it cannot display any data.

This time, the same Field above has been given context. It is now about “Bob Smith”. Since Bob Smith’s “First Name” is “Bob”, this Field can now display its appropriate data, which is, of course, just “Bob”. To say it a different way, it displays “Bob” because its context is now the Contact “Bob Smith”, and Bob Smith's first name is “Bob”.

Finally, we have given the First Name field a new context. It is now about “Nancy Jones”. As a result, we can see that the Field does its job, which is to display the “First Name” field of the Item about which it has context. So, it displays “Nancy”.

Actions receive context from their parents in a procedure. Lets imagine an Action whose function is to send an email to the Contact for which it has context.

If our send-email Action has been given the context of Bob Smith (said differently, “if it is about Bob Smith” then it will attempt to send an email to Bob Smith.

So, when this Action runs in this context, it will send an email to Bob Smith.

The very same Action at a different time may be about Nancy Jones (said differently, it’s context may be “Nancy Jones”). Its function is still to send an email to the Contact for which it has context. In this case, its context is Nancy Jones, and thus, when this Action runs in this context, it will send an email to Nancy Jones.

Context is passed by a concept known as inheritance. Recall the nesting of layouts and fields on a page (see WorkXpress 102)? Similarly, recall the hierarchical order of Actions in a procedure (see WorkXpress 103)? In short, Context is always passed from a parent block to a child Block. In other words, a child Block always inherits context from its parent.

For Layouts and Fields, this parent-child inheritance exactly follows the nesting used when creating the page. For Actions, this parent-child inheritance exactly follows the hierarchy of the procedure in question.

For example, recall the page about Bob Smith. Here, we've added Last Name and Address Fields.

This page was constructed with the following nested hierarchy:

Contact Home Page (A Page Layout)

  Contact Info - Bob Smith (A Field Grid Layout)
      First Name - Bob (A Short Text Field)
      Last Name - Smith (A Short Text Field)
      Address - 123 Main St, Anywhere, PA 00000 (An Address Field)

Therefore, if the Contact Home Page is about Bob Smith, through inheritance, the Contact Info Layout will be about Bob Smith. In turn, the First Name Field will inherit that same context from its parent, the Contact Info Layout, and be about Bob Smith as well. As a result, the First Name Field will display the value “Bob”. Both the Last Name and Address Fields display data about Bob Smith (Smith and his address, respectively) because they, too, inherit that context from the Contact Info Layout.

The context of a parent will, by default, be passed to any child. So, a Field will get its context from the Layout it is nested in, that Layout will get its context from the parent Layout it is nested in, and ultimately, all context will be derived from the Page Layout.

Where does a Page Layout get its context from? Usually, it gets its context from the link that caused it to be opened.

For example, the schematic below shows a list of Contacts. You can see three contacts in the list. If someone clicks on the link “Smith, Bob”, a Contact Home Page will be opened about “Bob Smith” (also said: ”…with the context of Bob Smith“).

However, if someone clicks on the link “Jones, Nancy”, a Contact Home Page will be opened about “Nancy Jones”.

You can see then that a link has the special ability to take its context and pass it to the page that it opens. In effect the Link Field is the parent Block of the Page Layout it opens.

In the below procedure there is an Action that sends an email to the Contact for which it has context:

The context that begins a procedure is always derived from the trigger that launched the procedure (see our previous lesson, The Logic Layer). That trigger is fired in some context, for example the saving of a page. So, if a user chooses to save the Contact Home Page about Bob Smith, the context of “Bob Smith” will be passed by the trigger to the procedure, as shown below:

You can see that if someone saves the page about Bob Smith, the end result will be an email sent to Bob Smith, because context is passed from the page, to the trigger, to the procedure, and finally to the Action whose job is to send an email to the Contact for which it was given context.

At a different time, the Contact Home Page is about Nancy Jones, and saving that page then results in an email being sent to Nancy Jones, as shown below:

Saving the page about Nancy Jones will fire a trigger, which will execute a procedure, which will execute an Action, and Nancy Jones will receive an email.

Thanks to the concepts of context and inheritance, all of this is possible.

Normally, a Block simply inherits its context and passes it on, unchanged, to any child Blocks; however, some blocks can be told, explicitly by you, the applicaiton builder, to make a change to the context. For example, any Layout or Field can be instructed to change its context at any time. This allows you to construct pages with information about multiple Items or Relationships and therefore to present a virtually unlimited variety of information to your users.

Similarly, some Actions can be set up to change context as well. This gives you the capability of constructing automation that performs complex tasks that act on a diverse array of Items or Relationships.

The ability to change context at any point in a procedure (Actions) or a nested hiearchy (Layouts and Fields) leads to the kind of highly sophisticated functionality previously reserved only for complex programming languages.

Any time a Layout, Field or Action has its context changed, all of its children, by default, will then inherit this new context.

Some Layouts, Fields or Actions have a primary function to change context. A List Layout is a good example of this.

List Layouts are commonly used to change context. For example, a list of Notes placed on a page about a Contact exists to show a series of Notes that were written about a particular Contact. If the Contact page has the context of “Bob Smith”, the Notes List Layout exists to show a list of Notes that were written about Bob Smith. Therefore, the list must redefine context to be about one or many Notes.

Recall the example above about how a Link Field is used to pass context to its target page. Clicking on the link for a particular Note in our List of Notes will take you to a home page about that Note. In other words, this list has caused context to be changed from the Contact, Bob Smith, to that of a Note that was written about Bob Smith.

Similarly, if we look at Nancy's notes, the context passes along in exactly the same manner.

In this example, someone created a list that allows a user to select multiple Contacts by checking them off. Then, they created a “Send Email” button (which is really a “mass action button”, a Link Field placed at the bottom of a List Layout). This is shown below:

The “send email” button is actually a trigger that fires the procedure shown below:

The Action which sends an email is setup only to send a single email at a time, but the procedure is given the context of each and every Contact the user selected. Therefore, we must change the context to a single Contact before passing Context to the “send email” Action.

Changing context in this fashion is the function of the “For-Each” control. It receives many Items or Relationships, then sequentially passes one at a time down the procedure. You can say this as “For each Contact, execute the following procedure”.

So, if the user checked off Bob Smith and Nancy Jones and clicks the Send Email button, the procedure will execute and the For-Each control will first pass Bob Smith and then it will pass Nancy Jones. “For each Contact, the send email Action will run”.

The end result is that one email will be sent to Bob Smith and another will go to Nancy Jones. Indeed, an email will be sent to every Contact in the list.

Understanding context will allow you to create applications with complex interfaces, navigation, and automation. Let's reiterate what we learned in this course:

1. Context answers the question “What am I about?” for a Layout, Field, or Action.

2. By default, context is inherited from a parent Block by a child Block.

3. You may change a Layout, Field, or Action's context at any time, and some Blocks exist for the primary purpose of changing context.

Thanks for taking the time to learn about context. You've nearly achieved Cloud Mastery. Keep to the path and continue on to Build Your First Application for a video tutorial that will help you create your first WorkXpress application!