FORTALECIMIENTO DEL SERVICIO DE SECADO Y COMERCIALIZACIÓN DE CAFÉ.

Some may perceive the Common Data functionality as unnecessary overhead. The Common Data functionality is a necessity, albeit (as described in the “Applicability” section) only when the Decoupled Navigation pattern is a necessity. The purpose of the Common Data functionality is to provide a wedge between the Action and Presentation functionalities, enabling a decoupling of functions.

Consider Figure 6-11, which illustrates the steps that occur when an HTML button is clicked, generating an event that causes a JavaScript function to be called.

Figure 6-11. Steps resulting from clicking a button

Figure 6-11 represents the simple button click as two steps. The first step is the HTML event, which processes the mouse click. The second step is the content generation in the table row below the button. The content uses HTML injection by assigning the innerHTML property. From this simple example, there would be no need for the Common Data functionality because that would add an unnecessary layer.

Let’s continue building on this example. Imagine that the same user interface is used to make a remote call via the XMLHttpRequest object. Figure 6-12 illustrates the steps needed in the remote case.

Figure 6-12. Steps resulting from clicking a button when using an extra XMLHttpRequest call

Figure 6-12 shows an added step (step 2), in which a request is made by using the

XMLHttpRequest object that then generates some data that is processed in step 3.

Looking at Figures 6-11 and 6-12, you might be wondering where the need for the Common Data functionality is. The need arises because often an application is converted from the state depicted in Figure 6-11 to that in Figure 6-12, or vice versa. Implementing the conversion can require some major restructuring of the code, or a completely new implementation that needs to be tested and maintained. The Common Data functionality decouples the steps so that an application that executed as in Figure 6-11 could be converted without major surprises into an application that executes as in Figure 6-12. The intention is to decouple, allowing the fewest number of changes and yielding the largest user benefit.

Consider the following code, which mimics the implementation of Figure 6-11:

function OnClick( event) {

document.getElementById( "myDiv").innerHTML = "data"; }

The code is a problem because what was defined as two steps in Figure 6-11 is one step in technical terms. The code is a function with an implementation. The problems of the function

OnClick are that the text identifier myDiv is hard-coded, and so is the assigned value data. Imagine that the assignment code is used in multiple places, and imagine that the text has to be converted to uppercase before doing the assignment. Then the code would have to be updated in multiple places.

The solution is to decouple the steps of Figure 6-11, which was illustrated as a single piece of code, into two code pieces. The decoupled code would be as follows:

function InjectHTML( elementId, text) {

document.getElementById( elementId).innerHTML = text; }

function OnClick( event) { InjectHTML( "myDiv", "data"); }

There are now two functions (InjectHTML and OnClick). The function InjectHTML requires an element identifier and some text, and will perform an HTML injection. The function

InjectHTML is a business-logic-specific implementation that operates on an HTML element reference defined by the client. The function OnClick reacts to the event and is responsible for gathering the data used to call the InjectHTML function. Each function has its responsibilities and each function is decoupled from the other. The only shared information is the data gath- ered by OnClick and processed by InjectHTML.

Figure 6-11 has been implemented by using a decoupled solution, but now Figure 6-12 needs to be implemented. This means that an additional step of using the XMLHttpRequest

object needs to be added. For simplicity, assume that the XMLHttpRequest object functionality is encapsulated in the function CallXMLHttpRequest, which accepts a single parameter. As the function CallXMLHttpRequest is used to gather information, the function is called by OnClick, and the returned data is passed to the InjectHTML function. The modified source code is as follows:

function InjectHTML( elementId, text) {

document.getElementById( elementId).innerHTML = text; }

function OnClick( event) {

InjectHTML( "myDiv", CallXMLHttpRequest( "data")); }

In the modified source code, the second parameter of the CallXMLHttpRequest function has been replaced with the function CallXMLHttpRequest. Looking at the solution technically, you can see that the three steps have been decoupled from each other, and each can vary without affecting the other. What is still kludgy is how the data is gathered and passed to the function InjectHTML. This is the reason for creating Common Data functionality.

The Common Data functionality replaces the kludgy calling of the functions with some common state. The problem at the moment is that the OnClick function relies on the functions

InjectHTML and CallXMLHttpRequest. The reliance cannot be avoided, but what can be avoided is the calling convention. Imagine that instead of InjectHTML being used, the function

InjectTextbox is used due to a business logic decision. And then imagine that InjectTextbox

requires an extra parameter, as illustrated by the following source code:

function InjectTextbox( convert, elementId, text) { // ....

}

function OnClick( event) {

InjectTextbox( false, "myDiv", CallXMLHttpRequest( "data")); }

Even though InjectTextbox and InjectHTML are similar, calling InjectTextbox requires a change in the logic of the OnClick function. The OnClick function has to make an additional decision of whether or not a conversion has to occur. You might say, “Well, duh, the OnClick func- tion has to change if the called function changes.” But the reply is, “Why must the OnClick function change?” The purpose of the OnClick function is to gather the data necessary to call either the

InjectHTML or InjectTexbox function. The purpose of the OnClick function is not to make decisions, because decisions can change if a user interface does not, and vice versa. The data gathering and decisions made about the data need to be decoupled.

In an ideal world where everything is decoupled, you would write the following source code:

<button onclick="Call( OnClick, null, InjectHTML)" />

<button onclick="Call( OnClick, CallXMLHttpRequest, InjectTextbox)" />

The modified source code has added the function Call, which has three parameters that are three function references. The first function reference, OnClick, is the Action functionality responsible for gathering the data into a state. The second function reference is either null or

CallXMLHttpRequest and represents the Common Data functionality that is responsible for processing the state. And finally, the third function references, InjectHTML and InjectTextbox, are responsible for displaying the state.

The resulting calling sequence illustrates that the first button click event gathers the data, does not process the data, and displays the data. The second button click event gathers the data, calls a remotely located server, and displays the data. The OnClick functions used in either button click event are identical, meaning that the OnClick event is not dependent on whether the processing of the common data is local or remote. So now the functions are decoupled, as is the calling sequence. The exact details of this decoupling and the calling of the functions is the topic of the following sections.