Top Banner
1 MORFEO MyMobileWeb http://mymobileweb.morfeo-project.org MyMobileWeb “Authoring adaptive Mobile Web Applications with MyMobileWeb” FIT-350405-2007-1 FIT-350401-2006-2
89

MyMobileWeb Certification Part II

Nov 27, 2014

Download

Business

crdlc

MyMobileWeb Basic Development http://mymobileweb.morfeo-project.org/
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: MyMobileWeb Certification Part II

1

MORFEO MyMobileWebhttp://mymobileweb.morfeo-project.org

MyMobileWeb“Authoring adaptive Mobile Web Applications with MyMobileWeb”

FIT-350405-2007-1FIT-350401-2006-2

Page 2: MyMobileWeb Certification Part II

2

MORFEO MyMobileWebhttp://mymobileweb.morfeo-project.org

Part II

MyMobileWeb Basic Development

Page 3: MyMobileWeb Certification Part II

3MO

RF

EO

MyM

obile

Web

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

Page 4: MyMobileWeb Certification Part II

4MO

RF

EO

MyM

obile

Web

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)

Page 5: MyMobileWeb Certification Part II

5MO

RF

EO

MyM

obile

Web

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)

Page 6: MyMobileWeb Certification Part II

6MO

RF

EO

MyM

obile

Web

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

Page 7: MyMobileWeb Certification Part II

7MO

RF

EO

MyM

obile

Web

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, …

Page 8: MyMobileWeb Certification Part II

8MO

RF

EO

MyM

obile

Web

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

Page 9: MyMobileWeb Certification Part II

9MO

RF

EO

MyM

obile

Web

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

Page 10: MyMobileWeb Certification Part II

10MO

RF

EO

MyM

obile

Web

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

Page 11: MyMobileWeb Certification Part II

11MO

RF

EO

MyM

obile

Web

High Level Execution Architecture (I)

Mobility Channel

HTTP

Productor WSRP 1

Event Handlers

MyMobileWeb Server

Platform

wml_1/presn.jsp

xhtml_mp/presn.jsp

html_wi_imode/presn.jsp

html_web/presn.jsp

Delivery Context Management AOs

Context

Control + Event + Data

Generated JSP’s

Data Binding

navigate

executeOA

Page 12: MyMobileWeb Certification Part II

12MO

RF

EO

MyM

obile

Web

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.).

Page 13: MyMobileWeb Certification Part II

13MO

RF

EO

MyM

obile

Web

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.

Page 14: MyMobileWeb Certification Part II

14MO

RF

EO

MyM

obile

Web

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

Page 15: MyMobileWeb Certification Part II

15MO

RF

EO

MyM

obile

Web

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,...

Page 16: MyMobileWeb Certification Part II

16MO

RF

EO

MyM

obile

Web

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

Page 17: MyMobileWeb Certification Part II

17MO

RF

EO

MyM

obile

Web

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

Page 18: MyMobileWeb Certification Part II

18MO

RF

EO

MyM

obile

Web

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

Page 19: MyMobileWeb Certification Part II

19MO

RF

EO

MyM

obile

Web

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

Page 20: MyMobileWeb Certification Part II

20MO

RF

EO

MyM

obile

Web

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

Page 21: MyMobileWeb Certification Part II

21MO

RF

EO

MyM

obile

Web

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

Page 22: MyMobileWeb Certification Part II

22MO

RF

EO

MyM

obile

Web

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

Page 23: MyMobileWeb Certification Part II

23MO

RF

EO

MyM

obile

Web

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

Page 24: MyMobileWeb Certification Part II

24MO

RF

EO

MyM

obile

Web

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)

Page 25: MyMobileWeb Certification Part II

25MO

RF

EO

MyM

obile

Web

• 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)

Page 26: MyMobileWeb Certification Part II

26MO

RF

EO

MyM

obile

Web

• 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

Page 27: MyMobileWeb Certification Part II

27MO

RF

EO

MyM

obile

Web

DB – Context Control – Example (II)

Page 28: MyMobileWeb Certification Part II

28MO

RF

EO

MyM

obile

Web

DB – Context Control – Example (III)

• Optionsbind attribute as List of Map’s

Page 29: MyMobileWeb Certification Part II

29MO

RF

EO

MyM

obile

Web

• 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)

Page 30: MyMobileWeb Certification Part II

30MO

RF

EO

MyM

obile

Web

• 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)

Page 31: MyMobileWeb Certification Part II

31MO

RF

EO

MyM

obile

Web

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

Page 32: MyMobileWeb Certification Part II

32MO

RF

EO

MyM

obile

Web

DB – Control Context – Example (II)

Page 33: MyMobileWeb Certification Part II

33MO

RF

EO

MyM

obile

Web

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

Page 34: MyMobileWeb Certification Part II

34MO

RF

EO

MyM

obile

Web

Multiple Layouts (II)

Page 35: MyMobileWeb Certification Part II

35MO

RF

EO

MyM

obile

Web

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

Page 36: MyMobileWeb Certification Part II

36MO

RF

EO

MyM

obile

Web

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

Page 37: MyMobileWeb Certification Part II

37MO

RF

EO

MyM

obile

Web

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

Page 38: MyMobileWeb Certification Part II

38MO

RF

EO

MyM

obile

Web

Client-Server Interaction (Session OK)

Control + Event + Data + Sequence

Data Validation

Update ContextDelegate Flow Engine

Sequence OK

Navigate Current View

Validation OKNavigate Error

View

Specific Event

No

No

Yes

Yes

No

YesHandle

Device

Page 39: MyMobileWeb Certification Part II

39MO

RF

EO

MyM

obile

Web

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)

Page 40: MyMobileWeb Certification Part II

40MO

RF

EO

MyM

obile

Web

Application Initializer (II)

• Reading application configuration file

Page 41: MyMobileWeb Certification Part II

41MO

RF

EO

MyM

obile

Web

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

• Configuration example (MyMobileWeb.Global.xml)

Page 42: MyMobileWeb Certification Part II

42MO

RF

EO

MyM

obile

Web

Session Initializer (II)

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

Page 43: MyMobileWeb Certification Part II

43MO

RF

EO

MyM

obile

Web

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

• Configuration example (MyMobileWeb.Global.xml)

Page 44: MyMobileWeb Certification Part II

44MO

RF

EO

MyM

obile

Web

Login Manager (II)

• My Login Manager extends CustomLogin Class

Page 45: MyMobileWeb Certification Part II

45MO

RF

EO

MyM

obile

Web

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

• Configuration example (MyMobileWeb.Global.xml)

Page 46: MyMobileWeb Certification Part II

46MO

RF

EO

MyM

obile

Web

Profile Manager (II)

• Login Manager example and JavaBean that stores the user profile

Page 47: MyMobileWeb Certification Part II

47MO

RF

EO

MyM

obile

Web

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

Page 48: MyMobileWeb Certification Part II

48MO

RF

EO

MyM

obile

Web

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 (optional) PO Login (optional) 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

Page 49: MyMobileWeb Certification Part II

49MO

RF

EO

MyM

obile

Web

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

Page 50: MyMobileWeb Certification Part II

50MO

RF

EO

MyM

obile

Web

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

Page 51: MyMobileWeb Certification Part II

51MO

RF

EO

MyM

obile

Web

Example - Handlers Hierarchy

Page 52: MyMobileWeb Certification Part II

52MO

RF

EO

MyM

obile

Web

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

Page 53: MyMobileWeb Certification Part II

53MO

RF

EO

MyM

obile

Web

Example – Event Handlers

• PO Handler Example

Page 54: MyMobileWeb Certification Part II

54MO

RF

EO

MyM

obile

Web

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

Page 55: MyMobileWeb Certification Part II

55MO

RF

EO

MyM

obile

Web

Application Operations (II)

• Select_OA implements an application operation that stores data for select control

Page 56: MyMobileWeb Certification Part II

56MO

RF

EO

MyM

obile

Web

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/

Page 57: MyMobileWeb Certification Part II

57MO

RF

EO

MyM

obile

Web

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.

Page 58: MyMobileWeb Certification Part II

58MO

RF

EO

MyM

obile

Web

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.

Page 59: MyMobileWeb Certification Part II

59MO

RF

EO

MyM

obile

Web

SCXML – Configuration

• MyMobileWeb.Global.xml

• Flow is defined in a file MyMobileWeb.Flow.xml

Page 60: MyMobileWeb Certification Part II

60MO

RF

EO

MyM

obile

Web

SCXML – Basic Example (I)

Page 61: MyMobileWeb Certification Part II

61MO

RF

EO

MyM

obile

Web

SCXML – Basic Example (II)

Page 62: MyMobileWeb Certification Part II

62MO

RF

EO

MyM

obile

Web

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

Page 63: MyMobileWeb Certification Part II

63MO

RF

EO

MyM

obile

Web

SCXML – Elements – initial

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

Page 64: MyMobileWeb Certification Part II

64MO

RF

EO

MyM

obile

Web

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: “NameOp”

• Presentation State: “NameOp_namePresentation”

• Generic State: “genericState”

• 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.

Page 65: MyMobileWeb Certification Part II

65MO

RF

EO

MyM

obile

Web

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

Page 66: MyMobileWeb Certification Part II

66MO

RF

EO

MyM

obile

Web

SCXML – Elements – onentry

• Executed when the state machine enters a state

Page 67: MyMobileWeb Certification Part II

67MO

RF

EO

MyM

obile

Web

SCXML – Elements – onexit

• Executed when the state machine leaves a state

Page 68: MyMobileWeb Certification Part II

68MO

RF

EO

MyM

obile

Web

SCXML – Custom Actionsmymw:executeOA

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

Page 69: MyMobileWeb Certification Part II

69MO

RF

EO

MyM

obile

Web

SCXML – Custom Actionsmymw:invokeMethod

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

Page 70: MyMobileWeb Certification Part II

70MO

RF

EO

MyM

obile

Web

SCXML – Custom Actionsmymw:logout

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

• Makes the navigation flow to restart

Page 71: MyMobileWeb Certification Part II

71MO

RF

EO

MyM

obile

Web

SCXML – Custom Actionsmymw: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.

Page 72: MyMobileWeb Certification Part II

72MO

RF

EO

MyM

obile

Web

SCXML – Custom Actionsmymw:showMessage

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

Page 73: MyMobileWeb Certification Part II

73MO

RF

EO

MyM

obile

Web

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

Page 74: MyMobileWeb Certification Part II

74MO

RF

EO

MyM

obile

Web

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

Page 75: MyMobileWeb Certification Part II

75MO

RF

EO

MyM

obile

Web

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.

Page 76: MyMobileWeb Certification Part II

76MO

RF

EO

MyM

obile

Web

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()”

Page 77: MyMobileWeb Certification Part II

77MO

RF

EO

MyM

obile

Web

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…)

Page 78: MyMobileWeb Certification Part II

78MO

RF

EO

MyM

obile

Web

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

Page 79: MyMobileWeb Certification Part II

79MO

RF

EO

MyM

obile

Web

Application Configuration – Step I

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

• Must be defined the configuration directory (web.xml)

Page 80: MyMobileWeb Certification Part II

80MO

RF

EO

MyM

obile

Web

Application Configuration – Step II

• LOG4J relative path is configured in MyMobileWeb.Global.xml

• Define traces parameters (logs/traces.xml)

Page 81: MyMobileWeb Certification Part II

81MO

RF

EO

MyM

obile

Web

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)

Page 82: MyMobileWeb Certification Part II

82MO

RF

EO

MyM

obile

Web

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

Page 83: MyMobileWeb Certification Part II

83MO

RF

EO

MyM

obile

Web

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

Page 84: MyMobileWeb Certification Part II

84MO

RF

EO

MyM

obile

Web

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

Page 85: MyMobileWeb Certification Part II

85MO

RF

EO

MyM

obile

Web

DeployTools Configuration – Generator III

• LOG4J Configuration (MyMobileWeb.CodeGen.xml)

• LOG4J path is configured in LOG4J_Config

• Define trace parameters (logs/traces.xml)

Page 86: MyMobileWeb Certification Part II

86MO

RF

EO

MyM

obile

Web

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

Page 87: MyMobileWeb Certification Part II

87MO

RF

EO

MyM

obile

Web

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

Page 88: MyMobileWeb Certification Part II

88MO

RF

EO

MyM

obile

Web

DeployTools Configuration – Extractor III

• LOG4J Configuration (MyMobileWeb.CodeGen.xml)

• LOG4J path is configured in LOG4J_Config

• Define trace parameters (logs/traces.xml)

Page 89: MyMobileWeb Certification Part II

89MO

RF

EO

MyM

obile

Web

Consortium