Task workflow at runtime
At runtime, most tasks follow a standard set of steps to process user data and generate and display results. Web Application Development Framework (ADF) JavaScript, Web ADF control classes, and task framework interfaces and implementations work together to support a task. The following illustration and workflow explains the task execution at runtime based on the topic, Creating a custom server task. The numbered blue circles indicate the sequence of events initiated by the task during an asynchronous partial postback.
The following references the preceding illustration:
-
A user action in the browser calls the executeTask JavaScript function in ESRI.ADF.Tasks.js that gets embedded to the application at runtime, for use by task controls that extend FloatingPanelTask. In the following code example, the onclick event of an element (for example, an .asp button) triggers the call to the executeTask JavaScript function:
onclick = "executeTask('textBoxValue=The Payload',"__esriDoPostBack
('TaskManager1$SimpleServerTask_CSharp1','TaskManager1_SimpleServerTask_CSharp1',
argument, ESRI.ADF.System.ProcessMSAjaxCallbackResult, context)");
- The executeTask function does the following before executing the task:
- Assigns a job ID to track asynchronous requests
- Initiates a postback to start the activity indicator in a TaskResults control (if one is buddied to the executing task.
- The startJob function constructs a list of argument\value pairs from the information that is being passed to it and invokes a JavaScript function (esriDoPostBack) for packaging all the information required to execute the task.
- The ASP.NET Asynchronous JavaScript and XML (AJAX) framework contains a component called PageRequestManager in a client-side and server-side framework. These components are the heart of ASP.NET AJAX partial page rendering. The Web ADF JavaScript function (esriDoPostBack) invokes a doPostBack function in the ASP.NET client-side framework PageRequestManager component passing all necessary information to its parameter (eventArgument). The following code example shows an argument string for executing the task with jobId 2 and "textBoxValue=The Payload" as custom argument:
After the postback to start the activity indicator, the startJob function is called to process user inputs for the task.
"EventArg=executeTask&taskJobID=2&textBoxValue=The Payload"
- Sys&WebForms$PagerequestManager$_doPostBack performs a series of checks by calling its other methods and finally posts the page back to the server asynchronously using PageRequestManager$_onFormSubmit(evt).
- On the server-side, the FloatingPanelTask inherits from FloatingPanel, which is inherited from the Web ADF abstract class, CompositeControl. This abstract class implements the IPostBackEventHandler interface and when the page gets submitted to the server, it invokes RaisePostBackEvent with the current event argument string.
- RaisePostBackEvent calls GetCallbackResult() in the task control class. The GetCallbackResult method in the task control class is used to retrieve the values for the custom argument values used by the task. The values are stored in a property named Input, which is defined by the ITask interface and implemented in and inherited from the FloatingPanelTask class.
- The CallbackEventArgument variable is parsed using the Web ADF CallbackUtility class to return a set of name\value (argument\value) pairs. In this case, only one custom argument (named textBoxValue) applies to the custom task, so it is assigned to the Input property. A final call to the base class (FloatingPanelTask), the GetCallbackResult method, continues the standard task processing.
See the following code example:
NameValueCollection keyValColl = CallbackUtility.ParseStringIntoNameValueCollection
(CallbackEventArgument);
Input = keyValColl["textBoxValue"];
return base.GetCallbackResult();
- The GetCallbackResult method in the FloatingPanelTask calls the methods to execute the task and construct the callback response string to display results in the browser. First, the CallbackEventArgument variable is parsed to determine the primary event argument, EventArg. The FloatingPanelTask checks for two specific values, startTaskActivityIndicator and executeTask. If startTaskActivityIndicator is confirmed, a callback response displays an activity indicator in a TaskResults control, if available. If executeTask is confirmed, the ExecuteTask method in the custom task class is called, followed by a call to the DisplayResults method in the FloatingPanelTask class to generate a callback string as shown in the following code example:
public override string GetCallbackResult()
{
NameValueCollection keyValColl =
CallbackUtility.ParseStringIntoNameValueCollection(CallbackEventArgument);
string eventArg = keyValColl["EventArg"];
string taskJobID = keyValColl["taskJobID"];
if (eventArg == "startTaskActivityIndicator")
{
// If the task is configured to hide the user interface when the task is executed, then
// hide it now so this initial callback can hide things immediately.
if (HideOnSubmit == true)
{
HideFloatingPanel();
}
StartTaskActivityIndicator(taskJobID);
}
else if (eventArg == "executeTask")
{
ExecuteTask();
OnExecuteTask(this);
DisplayResults(taskJobID, Input, Results);
if (ActivityIndicatorLocation ==
TaskActivityIndicatorLocation.InTaskTitleBar)
{
// Hide the AJAX indicator.
string script = string.Format("$get('{0}').style.display = 'none';",
AjaxActivityImageId);
CallbackResult cbresult = CallbackResult.CreateJavaScript(script);
CallbackResults.Add(cbresult);
}
}
else
{
return base.GetCallbackResult();
}
return CallbackResults.ToString();
}
Web ADF controls, resources, functionalities, and data source-specific application programming interfaces (APIs) can be used to process the input values (stored in the Input property). The results of a task execution can be stored in a property named, Results, which is displayed in the TaskResults control. The Results property is defined by the ITask interface, implemented in and inherited from the FloatingPanelTask class. It can be one of the following types:
- SimpleTaskResult
- DataSet
- TaskResultNode
For more information, see TaskResults control.
- The DisplayResults method in the FloatingPanelTask is called and provided with the results from the execution of the task. DisplayResults adds the Results object to a TaskResults control buddied to the custom task, if available. The TaskResults control has a DisplayResults method that works with predefined types (see the previous step) and renders Hypertext Markup Language (HTML) content for the control in a Web browser. Web ADF controls use CallbackResult objects to update browser rendering of the control (for more information, see AJAX capabilities in the Web ADF).
When the TaskResults control changes on the server, it generates a collection of CallbackResults for processing by the client (browser). The CallbackResults property of the custom task control, inherited from the CompositeControl class, is used to generate the callback response to the browser. As a result, CallbackResults from the TaskResults control need to be added to the custom task control's CallbackResults property. The DisplayResults method in the FloatingPanelTask control is shown in the following code example:
protected virtual void DisplayResults(string jobID, object taskInput, object
taskResults)
{
ITaskResultsContainer resultsContainer = null;
for (int i = 0; i < TaskResultsContainers.Count; i++)
{
resultsContainer = Utility.FindControl(TaskResultsContainers[i].Name, Page)
as ITaskResultsContainer;
if (resultsContainer != null)
{
resultsContainer.DisplayResults(this, jobID, taskInput, taskResults);
CallbackResults.CopyFrom(resultsContainer.CallbackResults);
}
}
}
- RaisePostBackEvent registers all the generated CallbackResult or CallbackResults as DataItem using the ScriptManager.RegisterDataItem method. The data items that are registered by using the RegisterDataItem method can be accessed in a client script during the pageLoading.
- The pageLoading event is raised after the response from the server to an asynchronous postback is received but before any content on the page is updated.
- The response string is directed to the registered partial postback response function, in this case, the Web ADF defined processCallbackResult function. This function parses the response for Web ADF controls on the client and triggers subsequent actions to update client-side display.
- Elements in the client browser are updated to reflect the new content from the callback response. In this example, the callback response updates the content of the TaskResults control with the results of a task executed on the server. This marks the completion of the asynchronous task execution.
For more information on tasks and creating custom server or user control tasks, see the topics referenced in the following See Also section.
See Also:
Introduction to the Task FrameworkServer task Manager integration
Creating a custom UserControlTask
Walkthrough: Creating a custom server task