Building click-across applications

You create applications in Mobile Web Studio from a variety of content sources, including Web, XML, database, JSP, and Web services elements. Portal Interface supports applications communicating with each other when they are placed on the same Portal Interface page or different pages.

UA also supports applications communicating with each other when they are placed on different pages within the same page group. See “Building composite applications” for details.

Mobile Web Studio includes a wizard-driven graphical user interface that allows you to build messaging applications without programming.

Messaging applications use a “click-across” mechanism, which uses the publish-and-subscribe model. Applications that communicate through a publish and subscribe paradigm require the sending application (publisher) to publish messages without explicitly specifying recipients or having knowledge of intended recipients. Similarly, a receiving application (subscriber) must receive only those messages in which the subscriber has registered an interest.

An application publishes notifications, which are received by a listening application subscriber. The publishing entity does not have to be aware of who or what has subscribed to its broadcasts. This allows for a flexible system where an application publishes multiple notices and a subscriber subscribes to multiple notices. Additionally, publishers can also be subscribers and subscribers can be publishers. An application can listen for an event while broadcasting another event.

When a user clicks an enabled link in an application with a defined event, the application broadcasts the event and passes along some data, such as the text on which the user clicked or the URL associated with the link. The parent page passes the event notification to applications on the same or other pages that have registered as listeners for that event.For example, some applications represent a series of navigation steps that are recorded during application creation and executed as a series of HTTP GETs and POSTs during playback. If an application contains CGI parameters from any GETs and POSTs, an application’s creator can override the CGI parameters to place input boxes above the application when it is played back. These input boxes allow the person viewing the application to enter their own data values in place of the CGI parameters.

If an application’s content contains tabular data, you can specify input parameters (commonly referred to as CGI parameters) during the application creation process.

An application’s creator can override the CGI parameters to place input boxes above the application when it is played back. These input boxes allow the person viewing the application to enter their own data values in place of the CGI parameters.

Figure 4-1 shows an application with the CGI parameter that corresponds to the Department Set ID. The value has been overridden and set to “AUS”.

When used in conjunction with click-across applications, you can automatically populate data passed to the application from the input boxes from data in another application on the same, or different, page.

The left application displays a list of Department Set IDs. The right application lists the employees for the given Department Set ID. When a user clicks the Department IDs in the left application, the selected ID is sent to the listening application on the right. Once the data is received, the listening application re-executes using the new data, and captures the resulting content.

Whether the listening application re-executes automatically depends on how you set the Auto Submit property in the Listener Editor when you define the application listener. If you selected Auto Submit when you define the listener, the listening application re-executes immediately. If Auto submit is not selected, the listening application does not re-execute instantly; click Refresh on the title bar to manually re-execute the listening application.

For example, if the user clicks the Belgium Department ID “BEL,” the string “BEL” is sent to the right application as input for the Department Set ID. The right application replays its capture sequence using the new query value of “BEL” and returns the result—the employee list for the Belgium department.

When developing click-across messaging applications, you are not limited to one parameter. As an application’s creator, you can override any number of parameters and set any number of those parameters to accept data from another application on the same page. Additionally, you can set any number of message events within an application, as explained later in this section.