MyMobileWeb Certification Part II

  • 733 views
Uploaded on

MyMobileWeb Basic Development http://mymobileweb.morfeo-project.org/

MyMobileWeb Basic Development http://mymobileweb.morfeo-project.org/

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
733
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
24
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. MyMobileWeb “Authoring adaptive Mobile Web Applications with MyMobileWeb” FIT-350405-2007-1 FIT-350401-2006-2
  • 2. Part II MyMobileWeb Basic Development
  • 3. 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
  • 4. 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)
  • 5. 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)
  • 6. 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
  • 7. 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, …
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. High Level Execution Architecture (I)
  • 12. 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.).
  • 13. 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.
  • 14. 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
  • 15. 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,...
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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)
  • 25.
    • 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)
  • 26.
    • 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
  • 27. DB – Context  Control – Example (II)
  • 28. DB – Context  Control – Example (III)
    • Optionsbind attribute as List of Map’s
  • 29.
    • 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)
  • 30.
    • 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)
  • 31. DB – Control  Context – Example (I) http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_UI_Data_Binding
  • 32. DB – Control  Context – Example (II)
  • 33. 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
  • 34. Multiple Layouts (II)
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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 )
  • 40. Application Initializer (II)
    • Reading application configuration file
  • 41. 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 )
  • 42. Session Initializer (II)
    • The “terminalWAP” variable is true when the preferred markup is wml_1
  • 43. 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 )
  • 44. Login Manager (II)
    • My Login Manager extends CustomLogin Class
  • 45. 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 )
  • 46. Profile Manager (II)
    • Login Manager example and JavaBean that stores the user profile
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. Example - Handlers Hierarchy
  • 52. 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
  • 53. Example – Event Handlers
    • PO Handler Example
  • 54. 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
  • 55. Application Operations (II)
    • Select_OA implements an application operation that stores data for select control
  • 56. 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/
  • 57. 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.
  • 58. 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.
  • 59. SCXML – Configuration
    • MyMobileWeb.Global.xml
    • Flow is defined in a file MyMobileWeb.Flow.xml
  • 60. SCXML – Basic Example (I)
  • 61. SCXML – Basic Example (II)
  • 62. 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
  • 63. SCXML – Elements – initial
    • This element represents the default initial state for a complex state with sequential substates.
  • 64. 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 .
  • 65. 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
  • 66. SCXML – Elements – onentry
    • Executed when the state machine enters a state
  • 67. SCXML – Elements – onexit
    • Executed when the state machine leaves a state
  • 68. SCXML – Custom Actions mymw:executeOA
    • mymw:executeOA : Allows the user to invoke an Application Operation (OA)
  • 69. SCXML – Custom Actions mymw:invokeMethod
    • mymw:invokeMethod : Allows the user to invoke a specific method in a concrete Java class.
  • 70. SCXML – Custom Actions mymw:logout
    • mymw:logout : This action allows the user to perform the typical MyMobileWeb logout.
    • Makes the navigation flow to restart
  • 71. 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.
  • 72. SCXML – Custom Actions mymw:showMessage
    • mymw:showMessage : This action allows the user to show a message to the user.
  • 73. 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
  • 74. 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
  • 75. 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.
  • 76. 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()”
  • 77. 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…)
  • 78. XML Events – Example – Change Type http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_XML_Events
  • 79. Application Configuration – Step I
    • Point of entry to the mobility platform ( DriverHTTP Servlet, web.xml )
    • Must be defined the configuration directory ( web.xml )
  • 80. Application Configuration – Step II
    • LOG4J relative path is configured in MyMobileWeb.Global.xml
    • Define traces parameters ( logs/traces.xml )
  • 81. 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)
  • 82. 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
  • 83. 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
  • 84. 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
  • 85. DeployTools Configuration – Generator III
    • LOG4J Configuration ( MyMobileWeb.CodeGen.xml )
      • LOG4J path is configured in LOG4J_Config
      • Define trace parameters ( logs/traces.xml )
  • 86. 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
  • 87. 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
  • 88. DeployTools Configuration – Extractor III
    • LOG4J Configuration ( MyMobileWeb.CodeGen.xml )
      • LOG4J path is configured in LOG4J_Config
      • Define trace parameters ( logs/traces.xml )
  • 89. Consortium