MyMobileWeb Certification Part II

MyMobileWeb “Authoring adaptive Mobile Web Applications with MyMobileWeb” FIT-350405-2007-1 FIT-350401-2006-2

Part II MyMobileWeb Basic Development

Contents

Introduction and concepts

High Level Execution Architecture

Authoring your user interface

IDEAL Language 1.1

User Interface Components

Styles

Data binding

Multiple Layouts

Selection

Client-Server Interaction

Java-Based Event Handlers

Defining the server-side behaviour using SCXML

Cool URIs

Defining client-side behaviour using XML Events

Configuration & Deployment

Introduction

MyMobileWeb is an open source platform that simplifies the development of mobile web applications and portals

A low-cost platform (no license fees). LGPL v 3.0

A modular product, open-standards-based

Other open sources technologies are used ( Device Information Simple API , Batik, Xerces, Xalan,…)

All-Java product that only requires a minimal Servlet/JSP container (Tomcat for example)

Provides different modules which cover all the basic requirements that must meet a complete and integrated mobile solution, hiding all the complexity related to dealing with multiple delivery contexts

Includes experimental modules related to the exploitation of semantics in a mobile environment

Applicability

dotMobi applications and portals

Mobile solutions intended to work in an uncontrolled environment (multiple devices)

Creation of mobile content channels based on JSR-170-based CMS or RSS

Offline / online mobile solutions (not covered in this course)

Vision

Mobile Web development should be driven by a “Channel Model” based on Service Oriented Architectures (SOA)

Applications publish business services that can be invoked from different channels: traditional Web Channel and Mobility Channel

Services are independent of the channel and need not to be duplicated

Mobile Channel is different than Web Channel (in general)

Markup transcodification is an anti-pattern

It has different views and navigation schema

Both channels can be integrated in the same server and CMS but they are essentially different

Aligned with the dotMobi vision

Typically a mobility channel only addresses a small percentage of functionality

Mobile Channel is composed by

Information that users want to access while they are on the move

Information that people want all the time

RAD of MultiChannel and MultiDevice Services (Reduction of time & budget and common development skills)

Main Features

“ Flexible authoring style that consists in to design once for all kind of delivery contexts, in addition to, when needed, a combination of adaptation policies and / or customized variants of few resources for specific delivery contexts”

Differential aspects against competitors

High performance architecture (no markup transcodification)

Automatic code generation for local (Javascript-based) and server-side validations

Smart Literal Management (literal redefinition)

Extensible mobile visual & AJAX controls

Intelligent management of paging for each visual control

Integrated with JSR-170 -based CMS & Alfresco

Available Image Transcoding (with OMA-STI and Alembik )

Media Set & Content Selection

Exploiting the Delivery Context (integrated with Device Information Simple API , Device clustering)

Being aware geolocation, screen orientation changes & context

Preliminary Concepts (I)

Presentation Operation (OP)

A set of presentations (views) plus their flow supporting an use case

Presentation Pseudo-Operation

POs that exit in all applications (platform-managed)

E.g. Login  entry point to the application (if any)

Presentation or view

Set of visual controls grouped in containers, allowing user interaction (specified in XML format)

Data binding

Technology that makes possible to automatically associate an element of data with a visual control and vice versa

Expression Language (EL)

Enables data referencing using dotted notation, delivery context functions, convenience functions, …

Preliminary Concepts (II)

Application Operation (OA)

A business-logic-related operation (e.g. querying the data of a company so the result is created in the context

Context

Hierarchical Data Store. It contains the data used by the application.

Context Levels: request, presentation, OP, session and application (compatibles with JavaServlet context levels)

Flow / Dialogue Manager

It is responsible of deciding what actions to execute in response to an event caused by the user in his device (AOs execution or navigate to a new presentation)

Delivery Context Management

Recognizes the user's device / web browser and find out their capabilities

Preliminary Concepts (III)

Style Manager

Determines which are the properties associated with each UI component, according to what is specified by the developer and to the technology and family of the destination device for which the presentation is generated

Validator

Implements the logic needed to automatically carry out the unitary validation according to what is specified by the developer at design time (locally & remotely)

Messages Manager

It shows messages in different languages which can be parameterized with context data

Literal Manager

It shows application literals in the appropriate language and it is possible to redefine literals by device families

Preliminary Concepts (IV)

Content Manager

It is in charge of finding the best resource for a specific delivery context, such as images, audios or videos

Code Generator

Generates the code for the presentations specified by the developer at design time

XML  JSP + Script code for validation + Mapping and validation meta-information XML files

Literal Extractor

Extract application literals to be translated

This component enables the development in the native language of each programmer without the need to handle literal identifiers

High Level Execution Architecture (I)

High Level Execution Architecture (II)

At the device side, when a user interaction causes an event to be treated at the server side, it is sent an HTTP request which contains:

the identifier of the visual control that raised the event.

the event identifier.

data that might have been entered by the user.

At the server side, the Delivery Context Management recognizes the device and retrieves all property values if it has not been done previously

The request is initially processed by the MyMobileWeb Server Platform. Then, data is validated, and if validations are ok, data items are stored in the context. The context is a container that holds all the model data items, and it is structured hierarchically in different scopes (application, session, use case, view, etc.).

High Level Execution Architecture (III)

There are two kind of events sent from the device:

Application-specific events

They have to do with the functionality of the application and are treated by specific handlers (well-known Java classes or SCXML) provided by programmers

MyMobileWeb-specific events

Handled automatically by MyMobileWeb, so application developers need not to worry about them (e.g. a next page event is raised when the user is paginating over the contents of a table)

Application-specific event handlers decide on how to process an incoming request

Typically they will call application operations (AOs) to get more data to be put into the model and, finally, a redirection to the next view (identified by a logical name) will be made

At this point, MyMobileWeb will be responsible of locating the appropriate JSP page according to the delivery context

This JSP page will render the presentation and will resolve all the data and content bindings with the help of runtime libraries.

IDEAL Language 1.1 (I)

Traditional user interface are insufficient for supporting the new generation service front-ends

Oriented to specific platforms, devices or modalities

Normally a PC device and GUI modality (big screen mouse & keyboard)

Imperative, platform and language-driven development style

UI designers cannot fully concentrate on the real application requirements

Developers often don’t understand the difference between

Authoring formats

A format intended for humans that provides as many abstraction levels as possible

Delivery formats

A format to be interpreted directly by the client platform (the web browser, for example)

HTML 4 / 5, CSS, etc are delivery formats

Unfortunately in many occasions are used as authoring formats

IDEAL Language 1.1 (II)

IDEAL is an Authoring Format easy-to-be learned by typical Web Authors for creating applications / content on the Ubiquitous Web

Simple things should be easy (80%)

Complex things should be possible (20%)

IDEAL v 1.1 is designed to deal with the problem of creating web applications that adapt to multiple Delivery Contexts

Based on simple containers and UI Components

Prepared to be used mainly over the Java Platform

CSS is used for guiding the adaptation process

We are designing the new generation of the IDEAL Language v 2.0

Modularization, extensibility (at the language and at the toolkit level), reusing markup, CSS cannot be sufficient to deal with adaptation policies,...

Containers

UI Components need to be grouped into containers. IDEAL v1.1 provides tow types of containers:

Div includes UI components (container nesting is not allowed). The layout can be horizontal , grid or vertical

It can be paginated if it has too many (for a given delivery context) child controls inside it

In that case the perceivable units by the user will be a set of screens chained by means of an interaction wizard

Section allows to switch between different subscreens, similar to 'tabs' in desktop applications (includes div containers)

There are different rendering options for a section container: multiple cards in WML, anchors in XHTML-MP, link to each subscreen, etc.

IDEAL v1.1 also provides mechanisms for reusing fragments of user interface definition markup between different presentations

The include tag is typically used for navigation bars

User Interface Components (I)

Label

It can contain any text and it’s used for labeling anything in an authored unit

Entryfield

This is an input field in which the user can enter any text

Developers can specify validations (required, datatype,…)

Link

This is a hyperlink that can be optionally decorated with an image

Separators ( br & hr )

Line break & horizontal rule respectively

Select

Allows the selection of one ore more values from a list which can be rendered as a combobox , radio buttons , checkbox , menu , etc. It depends on the style properties and the delivery context

http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Components

User Interface Components (II)

Menu

It allows the selection of one between several items and, after that, an event is raised

Menus can be rendered in different ways such as a list of links, a combobox sensitive to changes, clickable images,…

Menu items could be decorated with an image or even be numbered with direct access through access keys

MyMobileWeb takes care of the pagination of the menu (if needed)

ChainedMenu

It is a set of depending menus, i.e. the items of one menu depends on the value(s) selected in previous menus

A chained menu is rendered as a wizard in mobile phones and as a set of combos (popup lists) in PDAs

Submit

This control triggers an update of the model. When the user activates the control all the data in the current form on screen is posted to the server, starting the process of model (the context) updating, checking validations

User Interface Components (III)

Action

It’s a control to request something from the UI but no context updating occurs. Depending on the delivery context and the device it can be rendered as a button, as a link,…

Reset

Reset the fields of your form

Image

A control that displays a tiny picture in the screen which can be defined as value of src or resourceid attribute

List

Represents data in list mode. Each list item can be decorated using an image or an index number. Lists are paginated automatically according to the delivery context

Textarea

It is an area of free text (possibly with multiple lines) which can be readonly or disabled

User Interface Components (IV)

Table

Represents data in tabular mode and each column can be clickable or not depending on the style settings

Tables are automatically paginated if needed.

An interesting feature is that programmers can specify the visualization of more or less columns depending on the target delivery context

Object

It allows to put any multimedia object in a view. It has similar semantics than the 'object' tag in (X)HTML

Upload

It allows the user to upload files through Web o WAP from a desktop browser or mobile device to the server

Timefield

It represents an input field that accepts time as input (hours, minutes, seconds).

It is parameterized by means of a mask

User Interface Components (V)

Datefield

It is an input field that accepts a date as input.

Depending on the delivery context it can be rendered as a calendar, as a set of input fields or as a wizard

Phonebookadder

A visual component to add telephone number to my phone book. This control is an abstraction for developers that have not to worry about the different URL formats for specifying a phone book adder

TelephoneCaller

A visual component to trigger a phone call from a user interface page

This control is an abstraction for developers that have not to worry about the different URL formats for specifying a call

Styling (I)

MyMobileWeb has adopted CSS style sheets as the mechanism for specifying presentation aspects (look and feel, etc.) with respect to visual controls, validations (required or not, number mask, max & min length,…)

Each XML presentation file might be linked to one or more style sheets which must follow the CSS syntax

The properties and selectors that can be used are those specified in W-CSS plus some specific extensions defined by MyMobileWeb

MyMobileWeb fully supports the cascading pattern for applying style sheets

For instance, developers can specify a default style sheet that will apply to all the XML authored units.

Moreover, MyMobileWeb provides default CSS files that are applied when no style is specified by programmers

From a device independence perspective, the most important point is the style overriding feature

Using this feature a developer can change specific style properties of an authored unit depending on the delivery context.

For example, if a developer realizes that a background color is not readable on a device, she can easily change it for one another more suitable, by means of style overriding and without needing to change anything in the XML authored unit

Styling (II)

CSSs are stored in a directory which has as much subdirectories as redefinitions per markup technology or family of devices

Multi-Device CSS are stored into generic directory

Data Binding

All UI Components are ready to perform automatic binding on both directions

Context  UI Component  Context

Binding attributes

bind : contains the EL that addresses the datum at server side that will be automatically updated with user’s input

optionsbind : contains the EL that addresses the data at server side containing the items to be displayed by a UI component

validationtype : Indicates the type of validation associated with a Ui component (integer, string, date ...)

bindingtype : Indicates the type of the datum on which user’s input will be stored (Default coincides with validationtype )

beantype : Indicates the type of object which will be the container of user’s input ( Map by default)

Each UI component can define an optionsbind attribute with the EL that references its context data

Excepting entryfield where bind and optionsbind are the same

member attributes can be declared to specify the data member for each sub-element

E.g. each column of a table

It is developer’s responsibility to leave in context, under the corresponding key, the data to which each control is bound to

Before requesting the presentation

It is platform’s responsibility to take data from the context to render each control

MyMobileWeb doesn’t force to use default classes or data structures to perform automatic binding

Data Binding – Context  Control (I)

This example is based on table control

Several options for optionsbind attribute

Array of Java

List of List

List of Map’s

Any object that implements CollectionData interface

Member attributes

keymember: it is the key which is posted to server when one row is selected

member: it is the key which is posted to server when one row is selected

The value of member attribute can be pointed by name or position inside of an Array

Rows will be automatically paginated by MyMobileWeb (if needed)

DB – Context  Control – Example (I) http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Data_Binding

DB – Context  Control – Example (II)

DB – Context  Control – Example (III)

Optionsbind attribute as List of Map’s

Once satisfied the validation stage, data from the mobile terminal should be stored in the context at the place specified by the attribute bind

By default the data will become part of the context of PO, except that the EL specifies otherwise

E.g.: ${sessionScope.data1}

The data will be stored in the session context

The mappings are made by means of the files *_meta.xml (generated automatically)

By default data are stored in the context with the type of validation specified (default String )

If you want to store data in a type different from the validation type, then you must specify the attribute bindingtype

The Java simple types can be stored by wrapping or using classes Holder provided by the platform

Data Binding – Control  Context (I)

The controls that generate more than one data (such as select multiple) are mapped directly to a Java type List containing so many objects of validation type specified as the number of data generated by the control

If the EL bind expression refers to a composite item, for example, ${data1.data2} , it is needed to search in context for 'data1' and establish the value in property 'data2' from 'data1

If you can not find 'data1' an object of class specified by beantype will be instantiate, to store in context, in the key 'data1‘ and assign value on 'data2'

If no beantype attribute is specified, then a Map will be instantiate and it will be added a key ‘data2” with the correspondent value

Data Binding – Control  Context (II)

DB – Control  Context – Example (I) http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Data_Binding

DB – Control  Context – Example (II)

Multiple Layouts (I)

For achieving device independence, the layout of containers need to be specified using CSS properties

Using this method and the style overriding techniques provided by MyMobileWeb, a developer can alternate multiple layouts depending on different families of devices, tiny mobile phones, smartphones, PDAs, etc.

For example, in a PDA a designer would like to see a grid layout, because she has plenty of screen space whereas in a tiny mobile phone she would like to see a vertical layout

Using MyMobileWeb, this can be achieved easily without duplicating any code and without additional effort by the developer

http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Multiple_Layouts

Multiple Layouts (II)

Selection

The expr attribute is used to determine whether or not the UI Component appears in the target delivery context ( display attribute is deprecated )

Using data on context

expr="total gt 100"

User language

expr="_MYMW_LANG == 'es_ES'"

Device belongs to the abstract family

expr="dcn:belongsTo('PdaDevice') or dcn:belongsTo('PcDevice')"

Property values

expr="propertyValue('fileUploadSupport‘)”

expr="ddr:propertyValue ('scriptSupport')['ecmascript-MP']"

http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Selection

Client-Server Interaction

The generated pages always point to the same URL (corresponding to invoke the servlet DriverHTTP ), carrying at every moment the identifier of the visual control of the event that caused the output to the server

If the event may have associated parameters are also sent

E.g. the column of a table clicked

Additionally, the HTTP request contains data about the visual controls of the presentation

These data are properly identified in order to make the automatic binding

URLs are generated by the URLManager component, which takes into account whether the device supports cookies or not or even whether or not supports HTTPS

In each URL introduces two parameters control

_t  Timestamp to avoid caching in browsers

_s  Token sequence that solves the problem of button 'Back' browsers

Client-Server Interaction (new Session) Request Set context variables of Platform as Language, Token Sequence, ... Call Login PO Execute Profile Manager (user profile on context) and Session Initializer Login OK Recognize Device (Device instance on context) No Yes Call first application PO Device Execute Login Manager

Client-Server Interaction (Session OK) Control + Event + Data + Sequence Data Validation Update Context Delegate Flow Engine Sequence OK Navigate Current View Validation OK Navigate Error View Specific Event No No Yes Yes No Yes Handle Device

Application Initializer (I)

Applications could specify an initializer class which will be automatically invoked by the framework only once

This class can be used to initialize any type of component used internally by the application: pool, stubs, reading configuration files,...

The Initializer must be a class that implements the ApplInitializer interface

The specification of initializer implementation is optional

Configuration example ( MyMobileWeb.Global.xml )

Application Initializer (II)

Reading application configuration file

Session Initializer (I)

Initializer shall be in charge of executing session initialization (by each new session)

Context variables used internally by each session

It must implement SessionInitializer interface

Session Initializer is optional

Session Initializer (II)

The “terminalWAP” variable is true when the preferred markup is wml_1

Login Manager (I)

MyMobileWeb provides different Login Manager (several authentication mechanism)

Login Manager must implement ILoginManager interface

getLogin()

getPass()

login(user,pass)

Platform provides several mechanism which can be used by the application directly or inherit from them, example:

NoLogin to be specified by an application that doesn’t require a login page

RemoteUserLogin when the authentication is resolved using a RemoteUser mechanism

CustomLogin takes user and password from the HTTP request

CustomLoginLDAP derived form CustomLogin and performs the user validation against an LDAP Server

Login Manager (II)

My Login Manager extends CustomLogin Class

Profile Manager (I)

It is responsible of calculating the profile of the user each time it creates a new user session

Applications must implement the interface IProfileManager , which publishes a single method that allows the application to return the object that represents the user's profile

The user profile is stored in the session context and is available at any time using the utility class ContextUtil

Profile Manager (II)

Login Manager example and JavaBean that stores the user profile

Automatic Validations

Data sent from the presentations of mobile device are not stored in the context until unitary validations (automatic) has been passed

The validations can be local (resolved in scripting language) or remote resolved using the validation information in the * _meta.xml files

The validations are performed following several stages

Compulsory validations

Format validations

Type and range validations

If the unitary validations fails, it is generated an error message in the user language

When the validations is local, the script code automatically generated is executed

The multilanguage has been solved including the suitable script file

It is possible to incorporate specific validations of the application on script code

Extensible and open mechanism

MVC Framework Flow Definition

The design of the presentation layer and its grouping in POs and presentations determines the flow specification

The flow consist of

PO Welcome (o ptional )  PO Login (o ptional )  First Application PO  ...  PO N ...  Logout

The Flow Engine is a component that depending on the control and event fired by the user at the terminal, the PO, presentation and context data (state in the server side) decides what actions must execute

These actions will end by sending a new page to the user's terminal

There are events that are automatically managed by the framework

Pagination, Welcome, Login, Back message ....

It is a component that any application can develop freely implementing a Java interface automatically invoked by the framework.

MyMobileWeb provides two flow engines:

Java-Based Event Handlers (methods of Java classes)

SCXML

Flow engine based on handlers events

It is a flow engine that invokes methods of events handlers classes implemented by the developer of the application

They have the form

<controlId_event(RequestData,IActionExecutor)>

For example, if you would like to respond to onclick event of a control link with id ‘m1', you would write a method called

RequestData giving access to data of the current request (context, etc.)

IActionExecutor provides methods for implementing actions

Handler classes are placed in a base package (configurable) following a hierarchical structure determined by the POs

Event Handler

<Handler_Package_Base>.DefaultEventHandler

Global Handler of the application

E.g. a control 'Home' which always go to the first presentation of PO

<Handler_Package_Base>.<PO_Name>.<PO_Name>EventHandler

Handler for a whole PO

If you want that in a whole PO certain events are managed in the same way regardless of the presentation

onInitOP() method to put the code that enables the entry to the PO

Handler_Package_Base.<PO_Name>.<Presentation_Name>EventHandler

Presentation Handler

For a control and event, the search order of the handlers goes from the most specific (within the presentation handler that has the control), to the most generic (the default handler)

If at the end the event handler could not be located, it will go to the presentation that had been showed previously

Example - Handlers Hierarchy

Handlers: Action

When the handlers are invoked the data from the screen that caused the output to the server has been validated and established in the context (in the location specified by the bindings)

The code of the managers access to the context data and decide what action execute

Invoke an AO

Defined in the XML of AOs configuration

Call another PO (last action)

The call to another PO leads to destruction of all PO the context data of PO except those who decide to preserve or mapping

Show a presentation (last action)

The identifier of the presentation coincides with the name of the XML file that defines it, without extension

Show a message (last action)

Typically defined in the messages file

When entering a new PO onInitOP() method of the called PO is automatically invoked

Example – Event Handlers

PO Handler Example

Application Operations (I)

They are defined by an XML file, which indicates the class that implements such AO ( OAConfing.xml File)

It is ensures that for every AO there is only one instance in the entire application simultaneously accessed both by N threads

The AO must implement the ApplicationOperation interface

Init, executed only once in the whole application

Execute , where it is the AO code

It receives as parameter the context

The AO takes data from the context and stores data in it

Application Operations (II)

Select_OA implements an application operation that stores data for select control

SCXML

XML-based flow definitions with SCXML

General-purpose state-machine language.

W3C Working Draft : http://www.w3.org/TR/scxml/ (May 2008)

Commons SCXML Impl : http:// commons.apache.org/scxml /

MyMobileWeb currently uses commons SCXML 0.8

Based on the Working Draft published on 21 February 2007

http://www.w3.org/TR/2007/WD-scxml-20070221/

SCXML – Why to choose it

Advantages against Java-Based event handlers

Standards-based, avoids dependency on proprietary flow modeling mechanisms.

Easy to read, maintain and evolve.

Possibility to design the state machine with graphical tools.

Flexibility.

SCXML – Language - Core Elements

Core Elements : <scxml>, <state>, <transition>, <initial>, <onentry>, <onexit>

Other Elements : <parallel>, <history>, <final>

Executable Content : <event>, <if>, <elseif>, <else>, <log>

Custom Actions

mymw:executeOA : Allows the user to invoke an Application Operation (OA)

mymw:invokeMethod : Allows the user to invoke a specific method in a concrete Java class.

mymw:logout : This action allows the user to perform the typical MyMobileWeb logout.

mymw:propagateOpVars : This action allows the user to specify what context variables will be propagated to the next OP context, and also new possible parameters.

mymw:showMessage : This action allows the user to show a message to the user.

SCXML – Configuration

MyMobileWeb.Global.xml

Flow is defined in a file MyMobileWeb.Flow.xml

SCXML – Basic Example (I)

SCXML – Basic Example (II)

SCXML – Elements – scxml

It is the top-level root element.

Must define an initial state ( initialstate )

Must define MyMW namespace ( xmlns:mymw ) to use custom actions

SCXML – Elements – initial

This element represents the default initial state for a complex state with sequential substates.

SCXML – Elements – state

Represents a state within the state machine.

id attribute: The value of the id attribute will depend on the kind of state. This naming convention could change in a future.

OP State: “ N ame O p”

Presentation State: “ N ameOp _n amePresentation”

Generic State: “ g enericState”

src attribute: The value of the src attribute will be a relative (to the Flow_Base_URL) path containing material to be inserted into this state

http://localhost:8080/MyApplication/flows/FirstOp/Flow.xml .

SCXML – Elements – transition

Transitions between states are triggered by events

event attribute : MyMW Control + “_” + MyMW Event Identifier

cond attribute : Any MyMobileWeb boolean EL

target attribute : Target state

SCXML – Elements – onentry

Executed when the state machine enters a state

SCXML – Elements – onexit

Executed when the state machine leaves a state

SCXML – Custom Actions mymw:executeOA

mymw:executeOA : Allows the user to invoke an Application Operation (OA)

SCXML – Custom Actions mymw:invokeMethod

mymw:invokeMethod : Allows the user to invoke a specific method in a concrete Java class.

SCXML – Custom Actions mymw:logout

mymw:logout : This action allows the user to perform the typical MyMobileWeb logout.

Makes the navigation flow to restart

SCXML – Custom Actions mymw:propagateOpVars

mymw:propagateOpVars : This action allows the user to specify what context variables will be propagated to the next OP context, and also new possible parameters.

SCXML – Custom Actions mymw:showMessage

mymw:showMessage : This action allows the user to show a message to the user.

SCXML - Cool URI

A clean, elegant URL scheme is an important detail in a high-quality Web application. Maybe the most interesting arguments on why URLs should be clean and usable are:

Ability to bookmark and remember individual pages.

SEO related stuff: allow crawlers (e.g. Googlebot) to index the website, better URI naming…

Since MyMW version 3.4.1, the new SCXML Flow Manager defines:

A new event ( onrequest )

A function to define matching conditions for the requested URI against regular expressions.

See Cool URIs don’t change (by Tim Berners-Lee)

http://www.w3.org/Provider/Style/URI.html.en

SCXML - Cool URI Example

Define the mappings in MyMobileWeb.Flow.xml

Use them in your own presentations

http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_Cool_URIs

SCXML - Cool URI Restrictions

Cool URIs MUST start with /app

It is mandatory to define a generic “waiting” state because the application is not always going to start with the same PO.

Defining behaviour using XML Events

IDEAL v1.1 includes the Listener element of XML Events ( W3C Recommendation 14 October 2003 )

MyMobileWeb implements the target and observer attributes as xsd:IDREFS instead of xsd:IDREF

Developers can define behaviour using the Listener element and the script tag

This behaviour is define by means of Javascript code

If you want to use a listener element you should use the XML namespace identifier http://www.w3.org/2001/xml-events

Listener element is a child of head tag

Important: handler attribute does not need Javascript prefix

handler=“javascript: toggleColor()”

XML Events – DOM Events Types

Complete list of event types:

http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete

MyMobileWeb implements all previous event types expect types related to notification of any changes to the structure of a document (DOMNodeRemoved, DOMNodeInserted, etc…)

XML Events – Example – Change Type http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_XML_Events

Application Configuration – Step I

Point of entry to the mobility platform ( DriverHTTP Servlet, web.xml )

Must be defined the configuration directory ( web.xml )

Application Configuration – Step II

LOG4J relative path is configured in MyMobileWeb.Global.xml

Define traces parameters ( logs/traces.xml )

Application Configuration – Step III

General Properties are configured in MyMobileWeb.Global.xml

Login_Manager and initializers

First_Application_OP : first application PO

Context_Name: context name of the application

OA_Descriptor_File: AOs descriptor path

File with application specific configurations (if needed)

Application Configuration – Step IV

Delivery Context Management 3.4.1

View https://svn.forge.morfeo-project.org/svn/mymobileweb/trunk/MobilityChannelDocumentation/Presentaciones/Latest/MyMobileWeb_Certification_Part_III_04142009.ppt

DeployTools Configuration – Generator I

Basic configuration of an application used to perform the transformations ( MyMobileWeb.CodeGen.xml )

Several execution modes

Command line

Windows and Unix shell scripts provided by MyMobileWeb

ANT Build Tool ( http:// ant.apache.org /) and build.xml file

DeployTools Configuration – Generator II

The parameters that the Generator can receive are:

Directory with the configuration file (relative or absolute path)

By default is named config and it is optional

Application specification, POs and/or presentations to generate

/<Applicattion_Name>

/<Applicattion_Name>/<PO_Name>

/<Applicattion_Name>/<PO_Name>/<Pres_Name>

Examples

java org.morfeo.tidmobile.transform.Generator /SalesForce

java org.morfeo.tidmobile.transform.Generator /SalesForce/Login/login

DeployTools Configuration – Generator III

LOG4J Configuration ( MyMobileWeb.CodeGen.xml )

LOG4J path is configured in LOG4J_Config

Define trace parameters ( logs/traces.xml )

DeployTools Configuration – Extractor I

Basic configuration of an application used to perform the extractions ( MyMobileWeb.LiteralExtractor.xml )

Several execution modes

Command line

Windows and Unix shell scripts provided by MyMobileWeb

ANT Build Tool ( http:// ant.apache.org /) and build.xml file

DeployTools Configuration – Extractor II

The parameters that the Extractor can receive are:

Directory with the configuration file (relative or absolute path)

By default is named config and it is optional

Application(s) specification

/<Applicattion_Name>

Examples:

java org.morfeo.tidmobile.transform.Extractor /SalesForce

java org.morfeo.tidmobile.transform.Extractor /SalesForce /MyApplication

DeployTools Configuration – Extractor III

LOG4J Configuration ( MyMobileWeb.CodeGen.xml )

LOG4J path is configured in LOG4J_Config

Define trace parameters ( logs/traces.xml )

Consortium

MyMobileWeb Certification Part II

0 comments

Notes on slide 1

2 Favorites