ewd sen chat ouch tutorial 851 part1

8/4/2019 EWD Sen Chat Ouch Tutorial 851 Part1

1/55

EWD Mobile

Tutorial:Part 1

M/Gateway Developments Ltd http://www.mgateway.com

M/Gateway Developments Ltd
http://www.mgateway.com/http://www.mgateway.com/


2/55

Table of Contents

Introduction 1Background 1Pre-requisites 1

Lesson 1 3Hello World 3

Lesson 2 7Hello World Analysed 7

Lesson 3 10Some Simple Changes to Hello World

10

Lesson 4 12Buttons, Events, Hiding and Showing UI Elements 12

Lesson 5 16How EWD Custom Tags relate to Sencha Touch Classes 16

Lesson 6 21Accessing Data held in GT.M or Cach 21

Lesson 7 25Menus and Lists 25Adding a handler 27Adding a Slide Animation 28Using EWD to make the coding even simpler 29

Copyright 2011, M/Gateway Developments Ltd. All Rights Reserved

EWD Mobile Tutorial Part 1 (Build 857) i


3/55

Adding a Back Button 32Automating the Lists Back Button 34

Lesson 8 36Tab Panels 36Using EWD Fragments with the Tab Panel 37

Lesson 9 39Selecting Data from a List 39Creating our List 39Adding a NextPage 41Adding a Back Button 42Making the NextPage recognise the Item Selected from the List 42Retrieving more Details for the Selected Item 44

Appendix 1: Installing EWD 46Installing EWD 46GT.M 46

Cach 46Configuring EWD 46

Cach & CSP 47

1a) Simple Default Configuration

47

1b) Custom Configuration 472) Define CSP Application 47

Cach & WebLink 48GT.M 49Creating EWD Pages 49Running EWD Applications 50


EWD Mobile Tutorial Part 1 (Build 857) ii


4/55


EWD Mobile Tutorial Part 1 (Build 857) iii


5/55

Introduction

Background

EWD Mobile is a rapid application framework for mobile web applications. It is an extension of

Enterprise Web Developer (EWD) that integrates the Sencha Touch Javascript framework (http://

www.sencha.com), exposing it as a set of Custom Tags.

EWD Mobile allows extremely rapid development of Cach- and GT.M-based Mobile Web

Applications that look and behave like Native Applications, running on a variety of mobile devices

including the iPhone, iPad, Android phones and tablets and the Blackberry Playbook. EWD Mobile

applications will also run on desktop WebKit browsers such as Chrome and Safari.

Key benefits of using EWD Mobile are:

One application definition will run on all mobile devices that use WebKit browsers, instead of writing

separate versions of applications for the iPhone, iPad, Android devices, etc.

The development and maintenance effort is orders of magnitude less using EWD Mobile than writing

Native Applications for mobile devices

Distribution of applications and their updates is not dependent on their acceptance into an App Store.

This document provides a tutorial to help you learn how to build Mobile Apps using EWD Mobile.

Pre-requisitesBefore you begin this tutorial, you should install the latest build of EWD (build 857 or later). Details on

how to install and configure EWD are provided in Appendix I.

You will also need to install the latest version of the Sencha Touch Javascript framework. You can

obtain this from http://www.sencha.com.

This tutorial makes some assumptions about your configuration that are explained in detail in

Appendix I. The key assumptions are:

Your EWD Application root path will be:


EWD Mobile Tutorial Part 1 (Build 857) 1
http://www.sencha.com/http://www.sencha.com/http://www.sencha.com/http://www.sencha.com/http://www.sencha.com/http://www.sencha.com/http://www.sencha.com/


6/55

c:\ewdapps (Windows)

/usr/ewdapps (Linux)

If you are using Cach, youll be working in the USER namespace

If you are using GT.M, the instance youll be using is in/usr/local/gtm/ewd

Sencha Touch has been installed under your web servers root directory in a subdirectory named/

sencha-1.0

Youll need to adjust the examples appropriately if your configuration is different.



Note: if youre using a Windows default Cache CSP configuration and using the built-in web server

that uses port 57772:

You should install the Sencha Touch files into the directory path

c:/InterSystems/Cache/CSP/ewd/sencha

Dont add the version number (-1.0) to the path name as this appears to cause problems

In the examples that follow in these tutorials, anywhere you see the URL root /sencha-1.0,

substitute it with /csp/ewd/sencha


7/55

Lesson 1

Hello World

In time-honoured fashion, lets start this tutorial by creating a simple Hello World application that will

run as a mobile application. Well analyse in detail how this application works and what all the XML

means in the next section, but for now just try the following steps and see how little is involved in

developing mobile applications with EWD.

Were going to name this demo application stdemo, so youll be creating and editing files in the

directory c:\ewdapps\stdemo (or /usr/ewdapps/stdemo)

You can use any text or HTML editor to create and edit your EWD source pages. In this tutorial well

assume that you are using a simple text editor such as Notepad.

Create a text file namedindex.ewd(ie c:\ewdapps\stdemo\index.ewd) that contains the following:

Note 1: keep each tag on a single line ie dont include line breaks inside a tag

Note 2: if you are using CSP with the default built-in web server that runs on port 57772, see the notice on Page 2 above.

OK, lets compile and run this application. Start up a GT.M session or a Cach Terminal session and change to the USER

namespace. Type the following (depending on whether youre using GT.M, CSP or WebLink):

CSP: d compileAll^%zewdAPI(stdemo,,csp) WebLink: d compileAll^%zewdAPI(stdemo,,wl) GT.M: d compileAll^%zewdAPI(stdemo)Note the two commas if youre using Cach!

If youve properly installed and configured things, you should have seen something like the following:




8/55

USER>d compileAll^%zewdAPI("stdemo",,"csp")

c:\ewdapps\stdemo\ewdAjaxError.ewd

c:\ewdapps\stdemo\ewdAjaxErrorRedirect.ewd

c:\ewdapps\stdemo\ewdErrorRedirect.ewd

c:\ewdapps\stdemo\index.ewd

c:\InterSystems\Cache\CSP\ewd\stdemo\ewdLogout.csp

Load of CSP page started on 03/06/2011 17:11:39

Loading file C:\InterSystems\Cache\CSP\ewd\stdemo\ewdAjaxError.csp as cspCompiling file /csp/ewd/stdemo/ewdAjaxError.csp

Loading file C:\InterSystems\Cache\CSP\ewd\stdemo\ewdAjaxErrorRedirect.csp as csp

Compiling file /csp/ewd/stdemo/ewdAjaxErrorRedirect.csp

Loading file C:\InterSystems\Cache\CSP\ewd\stdemo\ewdErrorRedirect.csp as csp

Compiling file /csp/ewd/stdemo/ewdErrorRedirect.csp

Loading file C:\InterSystems\Cache\CSP\ewd\stdemo\ewdLogout.csp as csp

Compiling file /csp/ewd/stdemo/ewdLogout.csp

Loading file C:\InterSystems\Cache\CSP\ewd\stdemo\index.csp as csp

Compiling file /csp/ewd/stdemo/index.csp

Compiling class csp.stdemo.ewdajaxerror

Compiling class csp.stdemo.ewdajaxerrorredirect

Compiling class csp.stdemo.ewderrorredirect

Compiling class csp.stdemo.ewdlogout

Compiling class csp.stdemo.index

Compiling routine csp.stdemo.ewdajaxerror.1

Compiling routine csp.stdemo.ewdajaxerrorredirect.1

Compiling routine csp.stdemo.ewderrorredirect.1

Compiling routine csp.stdemo.ewdlogout.1

Compiling routine csp.stdemo.index.1

Load finished successfully.

USER>

You can now run the application. Start the browser on your mobile device and enter the URL:

GT.M: http://192.168.1.100/ewd/stdemo/index.ewdCSP: http://192.168.1.100/csp/ewd/stdemo/index.cspWebLink: http://192.168.1.100/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=stdemo&page=indexYoull need to change the IP address to that of your web server. If you are using a default CSP

configuration using the built-in web server that uses port 57772, the URL you should use is:

CSP: http://192.168.1.100:57772/csp/ewd/stdemo/index.csp


http://192.168.1.100:57772/csp/ewd/stdemo/index.csphttp://192.168.1.100/ewd/stdemo/index.ewdhttp://192.168.1.100:57772/csp/ewd/stdemo/index.csphttp://192.168.1.100:57772/csp/ewd/stdemo/index.csphttp://192.168.1.100/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=stdemo&page=indexhttp://192.168.1.100/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=stdemo&page=indexhttp://192.168.1.100/csp/ewd/stdemo/index.csphttp://192.168.1.100/csp/ewd/stdemo/index.csphttp://192.168.1.100/ewd/stdemo/index.ewdhttp://192.168.1.100/ewd/stdemo/index.ewd


9/55

What you should see, after a short pause while it loads everything up,

is this.

If youre running in an iPhone, iPod Touch or iPad, youll notice that

the application is running full screen without Safaris URL Location

window being visible. However, Safaris toolbar is still visible at the

bottom, and if you wanted to restart the application, youd need to

relaunch Safari and tediously re-enter that lengthy URL.

However, theres a further trick you can do on an iPhone or iPad

(Android devices have an equivalent procedure). Click that

rectangular symbol in the middle of the bottom toolbar and up will

pop the following:

Click the Add to Home Screen button

and youll see:

Click the blue Add button in the top right corner, and the Touch-

Icon that wed specified in theindex.ewdpages

tag will be added to your iPhones

Home Screen:




10/55

Now you can start our Demo application by simply touching the icon, just

as if it was a Native iPhone/iPad

App. Whats more, when you start

it up this way, youll see the startup splash screen, and when

the application is fully loaded and ready for use, youll no longer

see any trace of Safaris chrome:

Now it just looks like a Native App!




11/55

Lesson 2

Hello World Analysed

Hopefully youll agree that there wasnt much involved in getting an albeit very simple EWD Mobile

application up and running. Now lets take a more detailed look at what we did and why we did it.

Every EWD Application requires what is known as the Container Page or First Page. This is basically

an initial HTML page that acts as a container for the initial content and all subsequent content that willbe sent to the mobile browser by EWD. EWD applications use Ajax techniques for injecting chunks of

markup into the container page. As far as your browser is concerned, an EWD application is actually

a single page of HTML that never leaves the browser. EWD will handle all that Ajax stuff for you

automatically.

The Container Page can be named anything you like (avoid punctuation marks in names). However,

by convention, we usually name this pageindex.ewd. EWD pages must have a file extension

of.ewd.

So, our EWD Container page is the file we created namedindex.ewd. The reason we created it in the

path c:\ewdapps is because, in Appendix 1, that path was configured as whats known as the

Application Root Path. The Application Root Path is the directory under which EWDs compiler will

search for EWD applications. The name of each application is the same as the name you assign to

each subdirectory under the Application Root Path. We named our application stdemo, so thats

why we created the files in the directory c:\ewdapps\stdemo.

Now lets take a close look at the contents ofindex.ewd. Youll notice that the EWD files we created

just consist of XML (or XML-like) tags. In fact, as well see later, an EWD file can also contain HTML

tags and Javascript. Those of you who are familiar with technologies such as PHP or Java ServerPages will therefore realize that EWD is essentially whats generally known as a server pages

technology. However, since most of the EWD pages are just fragments of markup that are injected

into the Container Page, we refer to EWD as a server fragments technology. EWD differs

significantly from other server pages technologies in many ways. In particular, the level of abstraction,

ie the degree to which EWD describes what your application should do rather that how it should do it,

is very much higher than anything else in the web application development framework marketplace.

That means that you type less and your EWD files are a very succinct description of what each

fragment is going to be doing.




12/55

Heres index.ewdagain:

The tags in this file are known as Custom Tags.

The first one () is a generic EWD one with which all EWD pages must start. The

attribute isFirstPage=true tells EWD that this is the first page and can therefore be invoked using a

simple static URL. The attribute cachePage=false tells EWD to add a variety of HTTP responseheaders that will prevent your browser from caching the page, so you get a fresh copy loaded every

time you invoke it.

The second Custom Tag () and its child tags will generate all the HTML for the

Container Page. You simply need to specify a few attributes for your specific application:

rootPath: the name of the subdirectory under the web servers root directory where you installed

the Sencha Touch files. This is used by EWD to generate the URLs that will fetch the Sencha Touch

Javascript and CSS files.

title: the HTML title applied to the container page. Its also used as the default text for the touch

(startup) icon.

Inside the tags are a set of tags that define the URLs for the startup

images and icon. The type attribute defines their purpose:

icon: the path of the icon image file that a user can add to their iPhones Home Screen. This image

file should be 72 X 72 pixels in size and without rounded corners or gloss (EWD can add these

automatically). Youll find that the example file were referencing is included in the Sencha Touch

Kitchen Sink example source directory.

phoneStartupScreen: the path of the startup splash screen that will appear in a phone while the

first page is loading. This image file should be 320 X 460 pixels in size. Youll find that the example

file were referencing is included in the Sencha Touch Kitchen Sink example source directory.

tabletStartupScreen: the path of the startup splash screen that will appear in a tablet or desktop

browser while the first page is loading. This image file should be 768 X 1004 pixels in size. Youll

find that the example file were referencing is included in the Sencha Touch Kitchen Sink example

source directory.




13/55

Finally inside the tags is the tag inside which you define your initial

content. What weve specified is a simple tag.

Panels are the primary components that you use to define the UI of a Sencha Touch application. As

youll discover, there are many pre-defined types of panel, and panels can be nested inside each

other to pretty much any depth. In our simple Hello Worldapplication, we are using the simplest

panel possible. Weve told it to occupy the full screen, which is what your main outer panel should

always do, and were just defining its content using a simple htmlattribute.

The result, as you saw, was a pretty unimpressive looking Hello World message! However, we can

now begin to extend this application to make it look more like a proper mobile application.




14/55

Lesson 3

Some Simple Changes to Hello World

In this lesson were going to make some simple modifications to our Hello World application.

Lets first add a toolbar.

We can add a toolbar by using the tag which can be added inside any tag.

Toolbars can be docked to a variety of places in its parent panel, but the top and bottom are the usual

places. Well dock ours to the top of the main panel.

Lets try it. Editindex.ewdso it now looks like:

Re-compile this fragment file using:

GT.M: d compilePage^%zewdAPI(stdemo,helloWorld)CSP: d compilePage^%zewdAPI(stdemo,helloWorld,,csp)WebLink: d compilePage^%zewdAPI(stdemo,helloWorld,,wl)Note those two commas again if youre using CSP or WebLink! The compilePage() command justrecompiled theindex.ewdpage, leaving everything else unchanged.

Now try re-running the application by clicking on the EWD touch icon again. This time you should see

a toolbar at the top of the screen:




15/55

Already that looks better!

Next well add another toolbar, but this time well dock it the

bottom of the main panel, and well also make the main content

panel scrollable:

Recompile and re-run by clicking the EWD icon and you

should see theres now a bottom toolbar also:

Try swiping inside the main panel you should find the text

will scroll up and down and bounce back into position.




16/55

Lesson 4

Buttons, Events, Hiding and Showing UI Elements

Were now going to take a look at how you can add buttons into our example pages top toolbar and

how they can be used to control the UI.

Editindex.ewdso it now looks like this:

So weve added a toolbar button tag inside the top toolbar. Notice that weve also added anid

attribute to the bottom toolbar: youll see why later.

Recompile this page and try running the application again.

You should now see a button with the word Hide in it. Clicking or tapping it wont do anything

however: thats because we havent defined a handler for it. So lets add that now. Initially well just

show an alert message when the button is tapped:

EWD.sencha.onHideBtnTapped = function() {Ext.Msg.alert('Attention!', 'You clicked the Hide button!', Ext.emptyFn);

};




17/55

OK so what does this extra stuff do? We added a handlerattribute to the Hide toolbar button and

named it EWD.sencha.onHideBtnTapped. We then defined this as a function in the tag. The

tag allows us to add Javascript to the fragments payload. Theat=top attribute ensures that

it is sent before any of the Sencha Touch Javascript that is generated from the etc tags.

This is important in this instance because the handler function must be defined and exist before it is

attempted to be bound as a handler to the button.

This also raises an important point about the Sencha Touch tags. Unlike many of the more

conventional EWD Custom Tags that generate other HTML tags, the Sencha Touch tags generate

Javascript. Therefore if you also add your own Javascript into a fragment, you need to determine

whether it should be generated before or after the Sencha Touch code. Use theatattribute in the

tag to control this:

generates your Javascript before the Sencha Touch code

generates your Javascript after the Sencha Touch code

So, compile and run this new version. Now when you click the

Hide button youll see a Sencha Touch alert:

In fact there is no reason why the handler function needs to be

in the dynamically-generated EWD fragment. It would be better

if it was defined in a static Javascript file for a variety of reasons,

not least because the browser can cache it, but also because it

will be easier to maintain and debug. So lets do that.

Create a file named stdemo.js in your web servers root directory (eg c:\inetpub\wwwroot

or/var/www), containing the handler function:

EWD.sencha.onHideBtnTapped = function() {Ext.Msg.alert('Attention!', 'You clicked the Hide button!', Ext.emptyFn);

};




18/55

Remove the original version that we put inindex.ewd. Well now have to tell EWD to load the

stdemo.js file. We do this in theindex.ewdpage by adding a tag inside the

tag:

Note: if you are using a default CSP configuration with the built-in web server running on port57772, save stdemo.js into the directory c:\InterSystems\Cache\CSP\ewd and change the

tag in index.ewd to

Recompile and re-run the application. It should run identically to before.

We now know that our handler function is being correctly triggered when the Hide button is clicked,

but now lets make it actually hide something, specifically the bottom toolbar.

Now if you remember, we added anidattribute to the bottom toolbar, and now youll discover why we

did that. It provides Sencha Touch with a handle that we can use to invoke its various methods. Inthis example well invoke itshide() method. The key to this is the Sencha Touch function

Ext.getCmp(id) which returns the widget object with the specifiedid. So, change the

onHideBtnTappedfunction in stdemo.js as follows:

EWD.sencha.onHideBtnTapped = function() {Ext.getCmp("bottomToolbar").hide();

};

Because we simply changed the static Javascript file, theres no need to recompile any EWD pages

this time. Just restart the application in the mobile browser. This time, when you click the button, thebottom toolbar disappears.

So how can we get it to reappear? What would be nice would be to change the Hide button to say

Show, and make the toolbar reappear when its clicked, meanwhile changing the button to say

Hide again.

Its possible to change the button text and handler dynamically, but actually its a lot simpler to have

two buttons: Hide and Show, each with their own handler, and make the buttons hide and appear

at the right times. Try the following:




19/55

First amendindex.ewdas follows, adding the new Show toolbar button. Note how we initially make

it hidden:

Next amend stdemo.js as follows:

EWD.sencha.onHideBtnTapped = function() {Ext.getCmp("bottomToolbar").hide();Ext.getCmp("hideBtn").hide();Ext.getCmp("showBtn").show();

};

EWD.sencha.onShowBtnTapped = function() {Ext.getCmp("bottomToolbar").show();; Ext.getCmp("hideBtn").show();Ext.getCmp("showBtn").hide();

};

By making sure that the buttons also hadidattributes, we can alternately turn them on and off while

making the toolbar disappear and reappear.

Lets try one last trick before we finish this lesson. How can we move the buttons to the right hand

side of the toolbar? Thats easily done by using the tag:

Simply editindex.ewdas follows:

Now recompile and re-run the demo: now you should have the Hide button appearing on the left side

of the toolbar, and the Show button will appear on the right.




20/55

Lesson 5

How EWD Custom Tags relate to Sencha Touch Classes

In general, every EWD Sencha Touch tag is an XML representation of a corresponding Sencha Touch

Class. You can find the full API documentation for Sencha Touch classes athttp://dev.sencha.com/

deploy/touch/docs/

So, for example, the represents the Ext.Panelclass. As such, the can have, asan attribute, any of the simple name/value pair Config Options defined in the Sencha Touch API

documentation. However, the EWD Custom Tags can often have additional EWD-specific attributes

that are short-cut ways of describing commonly used behaviours, so youll probably find yourself

using very few of the available Config Options in your EWD pages.

You can supply the Config Options as attribute names. The names are not case sensitive as far as

you are concerned, but EWD will ensure that they are converted into the correct valid case-sensitive

names in the final compiled code.

Some of the Config Options described in the Sencha Touch API documentation are supplied as

objects or arrays, egitems, listeners, etc. In general, such Config Options should not be used in the

corresponding EWD Custom Tags since there are alternative mechanisms within the EWD Sencha

Touch tags for representing them. For example, when you nest tags inside each other,

EWD converts the inner ones into members of the items array of the outer ones. If you need a more

complex listener that cant be represented using the built-in shortcut techniques, you can use an

tag and child tags to represent them. However this type of advanced use

of the EWD Sencha Touch tags is beyond the scope of this tutorial.

Although EWD can be used to generate Sencha Touch applications without the author reallyunderstanding much about the Javascript that EWD generates, as with any tool, the more you can

learn about the Sencha Touch framework itself, the better youll understand whats going on under the

hood and the easier youll find debugging when things inevitably go wrong.

One of the best tools youll find for understanding and seeing what EWD is doing is the Developer

Tools panel that youll find in the desktop versions of the Chrome and Safari browsers. EWD Sencha

Touch applications will run perfectly in these browsers, and youll find that they become the preferred

development platforms for your work.

To bring up the Developer Tools Panel in Chrome, click the spanner (or wrench) icon in the top left

corner of the browser, and select Tools/Developer Tools from the menu:


http://dev.sencha.com/deploy/touch/docs/http://dev.sencha.com/deploy/touch/docs/http://dev.sencha.com/deploy/touch/docs/http://dev.sencha.com/deploy/touch/docs/http://dev.sencha.com/deploy/touch/docs/http://dev.sencha.com/deploy/touch/docs/


21/55

Initially youll find the Developer Tools panel appears at the bottom half of the browser window. Youll

find its a lot easier to use if you undock it by clicking its bottom left icon:

Youll also find it best to open up the Console sub-panel by clicking the icon next to the undock icon.If any Javascript errors occur youll see lots of useful detail in this Console panel this is invaluable

when trying to debug problems:




22/55

If you click on the Network tab you can see the source code that was sent to the browser for each

page or file that was fetched. If youre using WebLink, the EWD pages are all namedmgwms32.dllin

the list. If you use CSP

or GT.M, youll see the

pages named

index.ewdorindex.csp

etc.

Click on the first one

and youll see the

contents of the

Container page

(index.ewd) that was

actually sent to the

browser:



Click this icon to open the Console


23/55

You can cut and paste the

content into a text editor if

you want to view it in

detail.

Now scroll down through

the content of index.ewd

until you find the line

highlighted here:

Youll see a long line of Javascript that has been generated from the tags we placed inside the

tag. Its pretty difficult to read and understand, so heres a tip. Copy the Javascript line

shown in the example above, bring up the excellent online Javascript beautifier page (http://

jsbeautifier.org/), paste the generated code into the window and click the Beautifybutton. You should

now see the generated Javascript nicely laid out:

Now you can see that what was actually sent to the browser was an Ext.Panelconstructor that

defined our simple Hello Worldpanel, toolbars and buttons.


http://jsbeautifier.org/http://jsbeautifier.org/http://jsbeautifier.org/http://jsbeautifier.org/


24/55

If you study the code that EWD generated, youll begin to understand how the EWD Sencha Touch

tags relate to the Sencha Touch classes and their Config Options.

In the subsequent examples of this tutorial, you should use these tools to examine more closely

whats happening.




25/55

Lesson 6

Accessing Data held in GT.M or Cach

So far our demo application hasnt really done anything that couldnt have been done with static files.

The whole point of EWD is to allow a seamless integration with the GT.M and Cach database

environments. With EWD you can integrate with either M or Cach ObjectScript code and can

access data held in either Global storage or in Cach Objects. If you are using Cach you can also

use Cach SQL to query your databases. Additionally EWD will interoperate perfectly with Ensemble.

In Part 2 of this tutorial youll start to see how powerful and slick this integration really is, but lets finish

off this Part 1 of the tutorial with some simple examples of how we can access and use the GT.M or

Cach database.

Lets start by replacing that Hello Worldmessage with some information from the GT.M or Cach

database. What well use is an EWD function that returns the current version of EWD. We can invoke

this function from within the GT.M or Cach environment:

write $$version^%zewdAPI()

Edit theindex.ewdpage as follows:

What weve done is added what is known as a Pre-Page Scriptto the fragment. This is a GT.M or

Cach function that will be invokedbefore the fragment is rendered and sent to the browser. In EWD

Mobile applications, Pre-Page scripts are the only touch-point you have with GT.M and Cach. They

are what you use to fetch and marshall data from your database, and what you also use to validate

posted data and save it back to your database. Although youll be frequently using Pre-page scripts

in your applications, youll find that EWD does so much for you already that the amount of actual M or




26/55

Cach ObjectScript coding youll have to do will be pretty small, which is good news for development

speed and simplicity of downstream maintenance.

If you are using Cach, Pre-page scripts can either be M-style extrinsic functions or Cach Class

Methods. The example above is using the M-style extrinsic function style which is compatible with

both GT.M and Cach. If you wanted to use a Cach-style Class Method, youd express it as

something like:

Note that if you use Cach Class Methods, your EWD applications will only be able to be run on

Cach systems. If you use extrinsic functions and stick to standard M coding and Globals, you can

freely migrate your EWD applications between GT.M and Cach.

Youll also see that weve replaced the literal text Hello Worldin the tagshtmlattribute with

a reference to what is known as an EWD Session Variable: #version. Well examine the EWD Session

in greater detail in Part 3 of the Tutorial. For now just follow the example and see how it works.

So now we need to create that actual Pre-page Script in GT.M or Cach. Using an appropriate editor

in GT.M or Cach Studio, create the routine stdemo (eg stdemo.m in GT.M) containing the following:

stdemo ;;

getVersion(sessid);n version

;s version=$$version^%zewdAPI()d setSessionValue^%zewdAPI("version",version,sessid)QUIT "";

If you want to use a Cach Class Method, it would look like the following:

ClassMethod getVersion(sessid As %String) As %String{s version=$$version^%zewdAPI()d setSessionValue^%zewdAPI("version",version,sessid)

QUIT ""}

Notice that in both examples the calling signature is basically the same: the pre-page script function

musthave a single parameter: sessid. This is the unique EWD Session Idthat EWDs run-time

engine will automatically pass to your function. That Session Idis what provides access to the users

specific persistent Session information. EWD provides a whole range of APIs that allow you to access

and manipulate the users persistent Session data, and you see the simplest one being used here:

setSessionValue().




27/55

Notice also that a Pre-Page script mustalways Quit with a return value. By convention, a return

value of null (ie an empty string) means that the Pre-page script completed without any error

occurring.

So what this example pre-page script is doing is getting the EWD version string and putting it into an

EWD Session value named version.

In the EWD page we can then access that Session variable by using the reference to it: #version.

When you want to use an EWD Session Variable as the value of an attribute in an EWD Custom Tag,

just use the Session Variable name prefixed with #, eg as in our example:

So, save and compile your GT.M/Cach function and then re-compile theindex.ewdpage. Now run it

again and you should see:

There we go: our application is now displaying data that has originated in the GT.M or Cachdatabase!

Lets just make one final change to demonstrate a different way of using EWD Session Values, this

time within some standard HTML markup in our panel. We can do that by removing thehtmlattribute

and simply nesting some HTML markup inside the panel, eg:




28/55

Your version of EWD is:

Note that the block of markup must be encased in a single HTML tag: in this example were using a

tag. Inside that tag you can have any HTML markup you want.

This time, were going to display the contents of the EWD Session variable named version as some

text inside a tag. So this time we use the special syntax:

Those of you who are familiar with PHP will recognize this syntax. Note that the Session Variable

name must still be prefixed with a # to denote that this is a Session variable.

So, finally, compile and run the modified version ofindex.ewdabove and you should see:




29/55

Lesson 7

Menus and Lists

One of the primary UI components that is used in most mobile web applications is the menu or List.

The List is a particularly effective way of navigating and selecting from quite large amounts of data in

mobile devices because you can use a swipe gesture to quickly scroll through the list. The scrolling

list will have momentum and will continue to scroll by after a fast swipe gesture.

So lets change our simple Hello World application and make it start with a simple list of 3 options, the

first of which will take us to our Hello World page.

What we use to create menus in EWD is the Sencha Touch tag. The options or data in the

list are defined dynamically within Cach or GT.M. So edit theindex.ewdfile in your stdemo directory

as follows:

Now add the Pre-Page script functiongetMainMenu() to your stdemo routine, eg:

getMainMenu(sessid);n list;s list(1,"optionText")="Hello World"s list(2,"optionText")="Example 2"s list(3,"optionText")="Example 3";d saveListToSession^%zewdSTAPI(.list,"mainMenuOptions",sessid)

;QUIT ""




30/55

Once youve created and saved these files, recompile the stdemo application.

If youre using GT.M, youll also have to ensure that the routine file stdemo.m that contains the new

pre-page script has been re-compiled, by running, in the Linux shell:

mumps stdemo.m

Additionally if youre using GT.M, its also a good idea to signal to the EWD back-end processes that

they should be relinked. Do this from the GT.M shell by doing the following (make sure youre in the

correct file-path first, eg/usr/local/gtm/ewd):

$ mumps -direct

GTM> d relink^%zewdGTM

If youve done everything correctly, when you re-run the stdemo application you should see:

Lets take a look at what we did to create this. Specifically look atindex.ewdand its pre-page

script (getMainMenu):

First we used the tag which creates an instance of the Ext.Listclass

We added this as a sub-component of the main panel which is occupying the full screen of our

mobile device, so it sat inside the main panel and below the top toolbar




31/55

The pre-page script (getMainMenu()) creates a simple array of options. The first subscript (1..n)

denotes the position of the option in the list, and the second subscript (optionText) defines a

property that we want to use and/or display in the list.

The tag has a child tag which allows us to define how we want each row in the

list to be presented. In this example we just want to display the optionTextproperty, so we use the tag to denote that.

The option array that is created in the pre-page script is saved to the EWD Session as a JSON

datastore namedmainMenuOptions using the special EWD/Sencha Touch API: saveListToSession()

By defining the sessionName attribute of the tag to bemainMenuOptions, the list of options

we saved into the EWD Session using that name will be used to dynamically populate the List.

Note that we could have used any property name instead ofoptionText, but whatever name you use

in the options array must be referenced as an name within the tag.

Adding a handler

OK, so weve now displayed our list of options as a menu. However, its not doing much yet: tapping

any of the options will have no effect at present.

Thats because we havent defined any handler for the menu options yet. So lets change that. Asyoure going to discover, we have numerous options available to us now, but lets start with something

simple and well progressively make it slicker and powerful.

First edit theindex.ewdpage as follows:




32/55

What weve done is add an onTap attribute to the tag and weve added our Hello World

panel as an initially hidden sub-panel.

Now lets define that onTap handler function in the stdemo.js file:

EWD.sencha.helloWorld = function(index,record) {Ext.getCmp("mainMenu").hide();Ext.getCmp("helloworld").show();

};

The onTap handler function takes two parameters: index(the option number that you tapped: 0..n),

andrecord(the data record held in the tapped row)

In this first example, well simply hide the main menu and make the Hello Worldpanel appear in its

place. Remember that the idattribute of our Sencha Touch tags allows us to point directly to them

using Sencha Touchs Ext.getCmp() method.

If you save the edited stdemo.js file, recompile the modifiedmainMenu.ewdpage and re-run theapplication, you should now find that tapping any of the menu options will make the menu disappear

and the Hello World! Message will appear.

OK so thats a step forwards, but how can we make the Hello Worldmessage appear only if we click

the first menu option? Thats where the index parameter can be useful. Try editing the

EWD.sencha.helloWorld() function as follows:

EWD.sencha.helloWorld = function(index,record) {Ext.getCmp("mainMenu").hide();if (index === 0) Ext.getCmp("helloworld").show();

};

When you save stdemo.js and re-run the application, you should now find Hello World! only appears

when you click the first menu option.

Adding a Slide Animation

Thats getting better, but one of the cool features youll frequently see in mobile applications is the

animations such as sliding panels when you tap menu options, so lets now add that to our menu.

The first thing to understand is how animated sliding panels work conceptually in Sencha Touch.

What you require is a special type of containing panel. In Sencha Touch, panels can have a property

known as alayout, and there are a variety of layout types available. The one we require for sliding

animations is called a cardlayout, and in EWD you can specify this using the tag. We

need to make both the Listand our Hello Worldpanel to be members of this Card Panel in order for

them to be animated. So changeindex.ewdas follows:




33/55

What weve done is to wrap the tag inside a tag, and weve also

moved the Hello Worldpanel inside the . Only one panel at a time is displayed

in a Card Panel, and the first one is used as the one to initially be displayed. As a result we

can safely remove thehidden=trueattribute from thehelloworldpanel.

Now modify the EWD.sencha.helloWorld() function:

EWD.sencha.helloWorld = function(index,record) {if (index === 0)

Ext.getCmp("mainCardPanel").setActiveItem(Ext.getCmp("helloworld"),"slide");};

The Sencha Touch setActiveItem() function selects which panel is to be made visible (or active) inside

the Card Panel. Here well make the panel with anidofhelloworldthe active one, and we specify a

slide transition to provide the desired animation.

Save these files, recompile the application and now when you click the first menu option, the Hello

Worldpanel should slide into view. Now its starting to look cool!

Using EWD to make the coding even simplerAlthough we havent had to write much code to make this happen, EWD can make specifying menus

even quicker and simpler, with less reliance on explicitly using the underlying Sencha Touch Javascript

functions.

The first thing we can do is to programmatically specify the page associated with a particular option

within our pre-page script. We do that by adding an additional property to the array that defines the

page: well use a property namedpage for this, but you can choose any name you like:




34/55

getMainMenu(sessid);n list;

s list(1,"optionText")="Hello World"s list(1,"page")="helloworld"s list(2,"optionText")="Example 2"s list(2,"page")="example2"s list(3,"optionText")="Example 3"s list(3,"page")="example3";d saveListToSession^%zewdSTAPI(.list,"mainMenuOptions",sessid);QUIT ""

Now add this new field to the layout, but make sure its not actually displayed by setting

displayInList=false:

Now we can replace that onTap attribute with a special EWD attribute namednextPageField, and take

out the Hello Worldpanel:


35/55

Weve not seen an EWD fragment before so lets take a closer look at this one:

The first thing to notice is the tag. Unlike the Container page (index.ewd), the attribute

isFirstPage=false specifies that this is not a first page, so can only be accessed via a URL that EWD

automatically tokenizes with randomly-generated name/value pairs. What this means is that even if a

user was aware that your application included a fragment namedhelloWorld.ewd, they would be

unable to access that fragment arbitrarily via its associated URL it can only be accessed if the URL

includes the name/value pairs that EWD is expecting to also be attached to the URL. EWD

applications are highly secure as a result of this feature.

Notice also thepageType=ajax attribute. helloWorld.ewdis known as a fragment because it does

not contain a complete page of HTML: it is simply a fragment of content that will be injected, using

Ajax techniques, into the main container page. In the case ofhelloWorld.ewd, what will be injectedinto the Container page is actually the Javascript that defines the Hello Worldpanel. You dont need

to worry about how the Ajax stuff happens: EWD will look after it for you. All other EWD fragments

that you create should use the same tag as weve used forhelloWorld.ewd.

Back to what this fragment is going to do: the idea is that when we click one of the menu options, the

corresponding fragment will slide into view. In fact, we dont have to specify a transition since slide is

used by default. Just to make sure that our new mechanism will be used instead of our original

Javscript function, delete or comment out the EWD.sencha.helloworld() function from stdemo.js.

Now save the files and recompile the stdemo application (using compileAll^%zewdAPI) and try re-

running it.

You should find this behaves just like our first long-hand approach, but now were defining the menu

text and the associated page dynamically inindex.ewds pre-page script instead of using Javascript.

Theres another key difference in this approach: thehelloworldpanel is being injected into the

browsers page using Ajax techniques rather than pre-existing in the page and being made visible.

This has its downsides: a round-trip to the server is required to fetch the fragment. However it also

has many benefits, not least the fact that it allows us to break up the UI into small, manageable

chunks that can, if required, be developed and maintained independently by different people.

Now try trying some different transitions. Possible options are:

flip

pop

cube

fade

slide




36/55

For example:

As a final exercise in this part of the lesson, now try adding panels for the Example 2 and Example 3

options by creating separate EWD fragment files for them, ie example2.ewdand example3.ewd. They

should look similar to thehelloworld.ewdfragment we created above.

You should now have a fully functioning menu, with each of the three options bringing their respective

panel into view.

Adding a Back Button

Of course, by now it will be obvious to you that theres still a deficiency in our menu: its impossible to

go back to the main menu and choose a different option. The only way to see the main menu again is

to restart the application!

So lets fix that by adding a Back Button when we click a menu option and slide a fragment into view.

Once again there is the long-hand manual Sencha Touch mechanism and a simple automated

shortcut EWD mechanism. Lets use the Sencha Touch mechanism first, then well see how EWD

can simplify the process.

The first step is to add a back button into the toolbar inmainMenu.ewd:

The ui=back attribute specifies that we want a properly styled Back-button, and we want it initially

hidden. Weve also specified a handler, so lets define that next. What we need is a function that will

return the user to the main menu, reversing the slide transition. So lets add that to the stdemo.js file:

EWD.sencha.onBackBtnTapped = function() {Ext.getCmp("mainCardPanel").setActiveItem(0, {type:"slide", direction:

'right'});Ext.getCmp("backBtn").hide();Ext.getCmp("helloworld").destroy();

};




37/55

The setActiveItem() function is used again to return the List into view: notice that we use a 0 (zero) as

its first parameter to specify the first item in the Card Panel which was the List (ie the main menu).

The second parameter is an object that invokes a reverse slide transition.

When we return to the List, we want to hide the button again which is the purpose of the second

command. But what about that third command that uses the destroy() function: whats it there for?

The reason is because were using Ajax techniques to inject thehelloworldpanel (or one of the

others), and when we go back to the menu theres a good chance that well choose the same option

and inject another instance of thehelloworldpanel into the page. Because thehelloworldpanel is

actually represented as a complex set of Javascript objects within Sencha Touch, its going to get

horribly confused if we try to inject multiple instances of this same object into the page. We can avoid

that by getting Sencha Touch to destroy it and clear away all vestiges of it when we go back to the

List.

Theres one last thing we need to do: make the button appear when thehelloworldpanel slides intoview. Were using EWDs automatednextPageFieldmechanism, so we dont have an explicit handler

function that we have access to in order to show() the back button. However, we can add the

necessary Javascript into thehelloworld.ewdpage:

Ext.getCmp("backBtn").show();

This inline Javascript command will make the back button appear when the fragment is injected into

the page.

Try it all out: save the new versions of the files, recompile them and run the application again. You

should now be able to navigate to and fro between the Main Menu and the HelloWorldpanels, with

the back button appearing and disappearing at the correct times:




38/55

We still have a couple of problems:

we need to add copies of the Javascript logic that shows the back button to the other two

fragments that slide into view when you click the other two main menu options

that destroy() method is only being applied to thehelloworldpanel. What if the user chooses one of

the other options? Things will clearly go wrong.

You can easily fix the first issue. To fix the second, we need to change the Back Button handler to

identify and destroy whatever panel is the current one. Thats actually quite simple to do: heres the

modified version of the handler function:

EWD.sencha.onBackBtnTapped = function() {var cardPanel = Ext.getCmp("mainCardPanel");var currentPanel = cardPanel.getActiveItem();cardPanel.setActiveItem(0, {type:"slide", direction: 'right'});Ext.getCmp("backBtn").hide();currentPanel.destroy();

};

Note the way Ive set up variables named cardPaneland currentPanelthat are pointers to the

mainCardPaneland the currently active card panel objects: thats because Im making more than one

reference to each the objects in the logic, so its more efficient when done this way. As a side benefit I

think its also easier to read and maintain when written this way.

The key function here is the Sencha TouchgetActiveItem() function which returns the currently active

item in the Card Panel.

Now we have a totally general purpose Back Button handler. Try it for yourself.

Automating the Lists Back Button

So thats how to use the Sencha Touch functions to implement the back button with the required

behaviour. However, EWD can automate almost everything weve done manually.

Simply remove the uiandhandlerattributes from the back button tag inmainMenu.ewdand replace

them with type=autoback and cardPanel=mainCardPanel, ie:




39/55

For good measure you can delete or comment out the button handler that we previously added to

stdemo.js. Also remove the inline code that we previously added to the three fragments that brought

the back button into view. So, for example, thehelloworld.ewdfragment should look like this again:

Save the files, recompile the application and run it again: it should behave just as before, but this time

the back buttons appearance and disappearance now happens entirely automatically!




40/55

Lesson 8

Tab Panels

In Lesson 7 we saw how to create a simple menu and Card Panel that we could use for navigation.

In Sencha Touch there is an alternative UI technique which is the TabPanel. Instead of a list of options

in a menu, we can present the options as a set of tabs in a toolbar.

The advantage of this approach is its simplicity: the TabPanel looks after all the animation and to-ingand fro-ing between options for us. If youve only got a small number of menu/navigation options,

theyre probably the better technique to use.

So lets rewrite our application to use a TabPanel instead.

Editindex.ewdto look like the following:

Recompile the stdemo application and try running it again. This time you should see:




41/55

Try clicking the tabs and youll see the three sub-panels alternately slide in and out of view. This is

clearly a much simpler method to specify in order to allow navigation around your applications.

You can see, however, the key limitation: if youre running the application on an iPhone or Android

phone: you dont have much room for meaningful tab names. If you are running on a desktop or

tablet you have much more room, in which case tabs become a much more useful UI device.

Using EWD Fragments with the Tab Panel

You can also see that in order to use the TabPanel widget, you apparently need to specify all the sub-

panels and their contents in the same page. This can be advantageous, because no additional

round-trips to the server are required.

However, your application may be sufficiently large that you want to break it up into EWD fragments.

This is, in fact, possible to do, but one warning: sometimes, because of the way in which SenchaTouch handles the height of its panels, the rendering of injected panels from fragments fails. However,

if we keep the fragments and injected panels simple, we can demonstrate the technique.

Instead of having to explicitly use Sencha Touchs event handlers and functions, EWD Mobile makes it

very simple by allowing you to add an attribute namedpage to each of the panels for the

corresponding tabs, eg:




42/55

Now edit or create the three content fragment files as follows:

helloworld.ewd:

example2.ewd:

example3.ewd:

Recompile the stdemo application and now try running it. Each panel fragment should slide into view

when you click its corresponding tab. If you look in detail at what happens when you run it using

Chromes Developer Tools, youll see three parallel asynchronous requests are made for the content

fragments immediately afterindex.ewdis rendered.

The cool thing is that these requests are only made once when the Tab Panel is initially rendered, and

thereafter when you switch between tabs, youre working entirely locally in the browser.

Youll find that this demonstration works well. However, to reiterate the earlier warning: sometimes

youll find that whilst the fragment has been successfully injected into the container page and added

to its parent panel without any Javascript errors being reported, nothing will be visible. This is due to

the way in which Sencha Touch sizes and renders its panels and their contents.




43/55

Lesson 9

Selecting Data from a List

Were going to re-visit the tag, but this time well examine its role in displaying a set of data.

Well also look at how you can do something when the user selects an item from the list.

The differences to our previous example where we used a List as a UI navigation device are:

The list will contain the results of a database search rather than some predetermined options

We will probably want to perform the same action irrespective of the row in the List that is selected

by the user.

Creating our List

For this example well use one of the Globals that EWD will have created on your system, specifically

the one that holds the documentation for its DOM APIs. This will give us a nice long list of options to

display in our application.

Well use the Tab Panel that we created in the previous lesson, and well replace the middle panel

(example2) with a panel that will display the list of the APIs. Youll find that we cant add the List to

the TabPanel by using a separate fragment - it simply wont render. So editindex.ewdas follows:




44/55

When you are creating a List such as this inside a Tab Panel, its very important to follow a pattern

such as the one shown above otherwise Sencha Touch wont display anything. In particular, make

sure you have the attributes exactly as shown in red.

The tag is defined similarly to our previous example, and this time the list of options is being

held in an EWD Session variable named listOfAPIs. That is being created by the pre-page script:

getAPIList^stdemo. Heres what that function looks like:

getAPIList(sessid);n list,name,no;s name="",no=0f s name=$o(^%zewd("documentation","DOM","method",name)) q:name="" d. s no=no+1. s list(no,"optionText")=name;d saveListToSession^%zewdSTAPI(.list,"listOfAPIs",sessid);

QUIT ""

The global ^%zewd(documentation) is one that EWD will have created on your system when you

installed it. It contains quite a few records so its a good example to use in this demo application.

Save these files, routine, etc, recompile and run the application again and you should see the

following:

As you can see, clicking on the List tab brings up the list of APIs. You can try swiping through the

menu to see how quickly you can search and navigate through it.

So thats our menu displaying. Now how can we use it?




45/55

Adding a NextPage

Typically youll want the user to be able to tap a menu option and have a new panel slide into view

that presents some more specific information about the option they selected, either to simply view it

or manipulate it in some way. Lets see how to do that.

The first thing is to add two EWD-specific attributes to the tag in theindex.ewdpage (onlythat part ofindex.ewdis shown below):

ThenextPage attribute tells EWD the name of the fragment to fetch when any item in the list is

tapped. The cardpanelattribute tells EWD the idof the Card Panel that you want to use so that the

nextPage fragment can be both added to it and animated as it comes into view. Aslide transition is

used by default. Notice in index.ewdthat we specified the example2 panel to have alayout=card

for this purpose (as highlighted in red above).

We havent created the fragment namedapiDetails.ewdthat is referenced by thenextPage attribute,

yet, so lets do that now: create the file in your stdemo directory. Initially well keep its contents simple

just to check this step works correctly:

Save, compile and re-run the application as usual. This time when you tap any of the API names in

the list, our newapiDetails panel should now slide into view:




46/55

Adding a Back Button

Of course we now need a Back button in the toolbar to allow us to return to the list of APIs, so lets

add that. We use the sameautobackmechanism that was described earlier:

What weve done is to add a back button to the toolbar and automated it to work with the Card Panel

whoseidis example2. We initially make it hidden so that it only appears when thenextPage fragment

(apiDetails.ewd) slides into view. The attributes in red show how everything hinges around the

example2 id. Recompile and try running the application to see the back button working.

Making the NextPage recognise the Item Selected from the List

It should be clear by now that there is one remaining step that we need to understand in this exercise

to make it a really useful List example: how can we make theapiDetails.ewdfragment recognisewhich API we tapped in the List so that it can provide the user with information specific to that

particular one?

Actually its very simple. By using thenextPage attribute in the tag, EWD is already

automatically sending the number of the item you tapped as a name/value pair that is added to the

HTTP request forapiDetails.ewd. This number equates to the number in the option array that you

originally created in the pre-page script. So if the user taps the first item, EWD sends a value of 1.

For example, if you were using WebLink, the request for theapiDetails fragment would look

something like this:

http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp3

0&listItemNo=1&ewdrn=612485987

Highlighted in red is the name/value pair (listItemNo) that EWD added when the first API in the List

was tapped.

The trick is to process and make use of this request name/value pair in a pre-page script that well

now add toapiDetails.ewd:


http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987http://192.168.1.110/scripts/mgwms32.dll?MGWCHD=0&MGWAPP=ewdwl&app=stdemo&page=apiDetails&ewd_token=MWCFjJQIi9sShTZlEN1iXkYI2d3K55&n=v8eU35uZWEIWPVZKZMQ3eKJpgvHp30&listItemNo=1&ewdrn=612485987


47/55

In this pre-page script, we can pick up the value of that name/value pair using the EWD API

getRequestValue():

getAPIDetails(sessid);nlist,no,name;sno=$$getRequestValue^%zewdAPI("listItemNo",sessid)dmergeArrayFromSession^%zewdAPI(.list,"listofAPIs",sessid)sname=$g(list(no,"optionText"))dsetSessionValue^%zewdAPI("apiName",name,sessid);QUIT ""

Lets examine what this function will do:

It gets the value of thelistItemNo name/value pair using EWDsgetRequestValue() API. This

identifies the option selected by the user

It then retrieves the original list of options from the EWD Session, by using the

mergeArrayFromSession() method (this basically reverses the action of the saveListToSession()

method that was used in the pre-page script -getAPIList() forindex.ewd)

Now it can retrieve the name for the selected API from the options array by using the list number

that was sent by EWD

We can then save that name as an EWD Session value namedapiName. We can then refer to that

name in the fragments markup.

One last step: we want to display the value of the Session variable (apiName) that was created in the

pre-page script function.. EditapiDetails.ewd:

You selected the API named

Save all the files, recompile the stdemo application and run it again. Now when you tap an API in the

List, theapiDetails panel that slides into view should confirm the one you tapped, eg:




48/55

We now have a simple, but fully-functional menu that is driven by data held in GT.M or Cach.

Retrieving more Details for the Selected Item

Lets just add one final enhancement: well retrieve the purpose of the selected API from the ^%zewd

Global and display it in theapiDetails panel. Simply edit thegetAPIDetails() function in the ^stdemo

routine:

getAPIDetails(sessid);n desc,list,no,name;s no=$$getRequestValue^%zewdAPI("listItemNo",sessid)d mergeArrayFromSession^%zewdAPI(.list,"list",sessid)s name=$g(list(no,"optionText"))d setSessionValue^%zewdAPI("apiName",name,sessid)s desc=$g(^%zewd("documentation","DOM","method",name,"purpose"))d setSessionValue^%zewdAPI("apiPurpose",desc,sessid)

;QUIT ""

Now edit theapiDetails.ewdpage:




49/55

API:

Purpose:

Save, recompile and re-run the application. Finally we have a proper and useful application that

retrieves real details from your GT.M or Cach database in response to the user selecting from a

menu:

You now have enough knowledge to begin building mobile applications that can allow a user to

navigate through lists of data and then retrieve and display related information. Try modifying the

examples to use and display some of your own data.

That completes Part 1 of our EWD Mobile Tutorial. In Part 2 well introduce more widgets including

forms and well take a closer look at the mechanics of the EWD Session.




50/55

Appendix 1: Instal l ing EWD

Installing EWD

GT.M

You should either use the M/DB installer (http://gradvs1.mgateway.com/main/index.html?path=mdb/

mdbDownload) which will build you a system with the very latest build of EWD automatically, or get

the latest EWD routine files fromhttps://github.com/robtweed/EWD. See our website (http://www.mgateway.com) for details on installing EWD on GT.M systems.

Cach

You should download a copy of the latest version of EWD from our web site (http://

www.mgateway.com):

Click theEnterprise Web Developer tab

Click the tabsDownload EWD followed byEWD for Cach.

Complete the registration form and youll be able to download the latest copy of EWD for free. The

Sencha Touch custom tags are included in EWD.

The zip file that you'll download contains one critical file:

zewd.xml - the object code file that you install into your %SYS namespace using

$system.OBJ.Load(). Let this overwrite any existing copy of^%zewd* routines if you already have

EWD on your Cach system

Configuring EWD

EWD can generate CSP, WebLink and GT.M versions of Mobile web applications from the same EWD

application source code. If you're already using EWD, then you can immediately start developing

EWD applications.

If you're new to EWD, then you'll need to configure EWD for either WebLink, CSP or GT.M, depending

on which technology you use. There are configuration instructions on our web site, but here's a quick

way of configuring them, based on certain assumptions - just change the references according to

your exact GT.M or Cach/WebLink/CSP configuration.


http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/https://github.com/robtweed/EWDhttps://github.com/robtweed/EWDhttp://www.mgateway.com/http://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownloadhttp://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/http://www.mgateway.com/https://github.com/robtweed/EWDhttps://github.com/robtweed/EWDhttp://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownloadhttp://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownloadhttp://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownloadhttp://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownload


51/55

Cach & CSP

1a) Simple Default Configuration

If you are using a default Cach installation and want to initially use the built-in Apache web server

that is configured to use port 57772, you can just run (in a Cach Terminal session):

do configureDefault^%zewdCSP

This sets up the configuration global ^zewd for you.

1b) Custom Configuration

However, if you have configured IIS or some other web server for use with CSP, youll need to

manually configure EWD as appropriate to your specific configuration. This is done via the global

^zewd. Heres an example of how to do this:

Assumptions:

you'll be running your EWD-generated CSP applications in your USER namespace

you're using IIS as your web server and its root path is c:\inetpub\wwwroot

your source EWD applications will reside under the path c:\ewdapps

the CSP application directories and files generated by EWD will be saved under

c:\InterSystems\Cach\CSP\ewd

Create a global named ^zewdas follows (adjust as necessary):

^zewd("config","RootURL","csp")="/csp/ewd"

^zewd("config","applicationRootPath")="c:\ewdapps"

^zewd("config","outputRootPath","csp")="c:\InterSystems\Cache\CSP\ewd"

^zewd("config","jsScriptPath","csp","mode")="fixed"

^zewd("config","jsScriptPath","csp","path")="/"

^zewd("config","jsScriptPath","csp","outputPath")="c:\Inetpub\wwwroot"

2) Define CSP Application

Next, you must create a CSP Application named "/csp/ewd" that points to the outputRootPath above

and directs you to the required namespace (USER). To so this, use the Cach System Management

Portal, select Security Management/ CSP Applications, then click the Create New CSP Application

link.

Fill out the form as shown below to get you started:




52/55

The settings shown above are for a simple default CSP system using the built-in web server. If you

have a customized CSP configuration, you may need to make some adjustments, in particular to theCSP Files Physical Path.

EWD should now be ready to use with CSP.

Cach & WebLink

Assumptions:

you'll be running your EWD applications in your USER namespace

you're using IIS as your web server and its root path is c:\inetpub\wwwroot

your source EWD applications will reside under the path c:\ewdapps

you'll be using the WebLink Server (MGWLPN) LOCAL which, by default, connects incoming

requests to the USER namespace

Create a global named ^zewd in the USER namespace as follows (adjust as necessary):




53/55

^zewd("config","RootURL","wl")="/scripts/mgwms32.dll"

^zewd("config","applicationRootPath")="/usr/ewdApps"

^zewd("config","jsScriptPath","wl")="fixed"

^zewd("config","jsScriptPath","wl","mode")="fixed"

^zewd("config","jsScriptPath","wl","outputPath")="c:\Inetpub\wwwroot"

^zewd("config","jsScriptPath","wl","path")="/"

You also must create the global (again in USER):

^MGWAPP("ewdwl")="runPage^%zewdWLD"

This latter global creates the WebLink dispatcher to EWD's WebLink run-time engine.

GT.M

Assumptions:

you'll be running your EWD applications in an instance of GT.M running in/usr/local/gtm/ewd

you're using Apache as your web server and its root path is/var/www

your source EWD applications will reside under the path/usr/ewdapps

m_apache has been installed and configured to dispatch to EWDs runtime code when URLs are

encountered containing/ewd

Javascript and CSS files that are generated by EWD will be saved under the webserver

path/resources

Create a global named ^zewd as follows (adjust as necessary):

^zewd("config","RootURL","gtm")="/ewd/"

^zewd("config","applicationRootPath")="/usr/ewdapps"

^zewd("config","jsScriptPath","gtm","mode")="fixed"

^zewd("config","jsScriptPath","gtm","outputPath")="/var/www/resources"

^zewd("config","jsScriptPath","gtm","path")="/resources/"

^zewd("config","routinePath","gtm")="/usr/local/gtm/ewd/"

Creating EWD Pages

This tutorial will guide you through the process, but heres a quick summary of the process involved,

based on the configuration settings shown above.

Having configured your EWD environment, you should now be ready to start developing. Create your

new EWD application source pages in subdirectories of the Application Root Path, eg if your

Application Root Path is c:\ewdapps and your application is namedmyApp::




54/55

c:\ewdapps\myApp\index.ewd

c:\ewdapps\myApp\login.ewd

You can use any text editor to create and edit these files.

To create an executable web application from these pages, you must compile them. This is most

easily done using the command-line APIs that you invoke from within Cach Terminal or, if you are

using GT.M, from within a Linux terminal session running the GT.M shell.

To compile an entire application (eg one named myApp):

CSP:

USER> d compileAll^%zewdAPI("myApp",,"csp")

WebLink:

USER> d compileAll^%zewdAPI("myApp",,"wl")

GT.M:

USER> d compileAll^%zewdAPI("myApp")

To compile one page (eg myPage.ewd) in an application (egmyApp):

CSP:

USER> d compilePage^%zewdAPI("myApp","myPage",,"csp")

WebLink:

USER> d compilePage^%zewdAPI("myApp","myPage",,"wl")

GT.M:

USER> d compilePage^%zewdAPI("myApp","myPage")

Running EWD Applications

Youll now have a runnable iPhone Web Application. You start it using the web server in your mobile

device (eg Safari on the iPhone). The structure of the URL youll use depends on whether youre

using GT.M, WebLink or CSP:




55/55

CSP

For CSP EWD applications, the structure of the URL youll use is:

http://127.0.0.1/csp/ewd/[applicationName]/[pageName].csp where: applicationName is the name of your EWD application pageName is the name of the first page of your EWD application for example: http://127.0.0.1/csp/ewd/myApp/index.cspWebLink

For WebLink EWD applications, the structure of the URL youll use is:

http://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=[applicationName]&page=[pageName]

where applicationName is the name of your EWD application pageName is the name of the first page of your EWD applicationfor example:

http://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=index

If youre using Apache, youll typically replace/scripts/mgwms32.dllwith cgi-bin/nph-mgwcgi

Of course if youre using a WebLink Server other than LOCAL, youll also need to change the value of

the MGWLPNname/value pair.

GT.M

For GT.M EWD applications, the structure of the URL youll use is:

http://127.0.0.1/ewd/[applicationName]/[pageName].ewd where applicationName is the name of your EWD application pageName is the name of the first page of your EWD applicationfor example:

htt //127 0 0 1/ d/ A /i d d

http://127.0.0.1/ewd/%5BapplicationName%5D/%5BpageName%5D.ewdhttp://127.0.0.1/ewd/%5BapplicationName%5D/%5BpageName%5D.ewdhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=%5BapplicationName%5D&page=%5BpageName%5Dhttp://127.0.0.1/csp/ewd/myApp/index.csphttp://127.0.0.1/ewd/%5BapplicationName%5D/%5BpageName%5D.ewdhttp://127.0.0.1/ewd/%5BapplicationName%5D/%5BpageName%5D.ewdhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=myApp&page=indexhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=%5BapplicationName%5D&page=%5BpageName%5Dhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=%5BapplicationName%5D&page=%5BpageName%5Dhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=%5BapplicationName%5D&page=%5BpageName%5Dhttp://127.0.0.1/scripts/mgwms32.dll?MGWLPN=LOCAL&MGWAPP=ewdwl&app=%5BapplicationName%5D&page=%5BpageName%5Dhttp://127.0.0.1/csp/ewd/myApp/index.csphttp://127.0.0.1/csp/ewd/myApp/index.csphttp://127.0.0.1/csp/ewd/%5BapplicationName%5D/%5BpageName%5D.csphttp://127.0.0.1/csp/ewd/%5BapplicationName%5D/%5BpageName%5D.csp

ewd sen chat ouch tutorial 851 part1

Documents