EWD Python Tutorial Part 1

Developing Ajax Applications using EWD and Python

Tutorial: Part 1

Chapter 1: Introduction

BackgroundEnterprise Web Developer (EWD) is a framework for developing and running sophisticated and secure Ajax applications. EWD's key design objective was extremely rapid and simple development, combined with extremely easy maintenance, making it the most productive Ajax development platform currently available.

EWD differs markedly from most of the most well-known Ajax frameworks in that it eschews the programmer-orientated Model/View Controller(MVC) paradigm and instead places the designer at the focus of the development process, with programming reduced to a relatively trivial aspect of the overall process. The majority of the work that would be required in an MVC-based framework is automated in EWD, leaving the development team able for focus their time and efforts on describing what the application should do rather than how works.

This tutorial aims to demonstrate how quickly and easily an Ajax application can be developed using EWD. EWD applications can be developed using a variety of languages, and this tutorial focuses on the use of Python.

PrerequisitesYou'll need a Linux system with GT.M and EWD installed. The quickest and easiest way to do this is to use the M/DB Installer (http://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownload). The M/DB Appliance that the installer builds includes a pre-configured, ready to run EWD and GT.M environment, complete with the Python utilities we'll use in this tutorial.

This document will assume you're using a default EWD environment as configured in the M/DB Appliance. Adjust any path references etc as required if you're using a different EWD set-up.

If you're developing from within a Windows environment, my recommendation is to use WinSCP (http://winscp.net/eng/index.php) to create and edit your EWD pages on your Linux system, and use puTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) to execute code on the Linux system.

You'll also need a standard web browser to run the applications that you'll be building with EWD and Python.

Let's get started!

Developing Ajax Applications using EWD and Python: Tutorial Part 127 November 2009. 2009, M/Gateway Developments Ltd. All Rights Reserved

1

http://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownload

http://gradvs1.mgateway.com/main/index.html?path=mdb/mdbDownload

http://www.chiark.greenend.org.uk/~sgtatham/putty/

http://winscp.net/eng/index.php

Chapter 2: A Simple Hello World

No tutorial is complete without an initial Hello World application, so let's build one with EWD.

First let's create a directory to hold the source pages that we'll be writing in this tutorial. The directory I'll be using is /usr/ewdapps/tutorial. Assuming you're using the M/DB Appliance, you'll find that the directory /usr/ewdapps already exists, so just add tutorial, eg from the command line:

cd /usr/ewdapps

mkdir tutorial

You may need to set the permissions, eg:sudo chmod 755 tutorial

Now create a file named helloworld.ewd containing the following text and save it in the tutorial directory

<ewd:config><html><head><title>EWD Python Tutorial: Hello World</title></head><body><p>Hello World!</p></body></html>

In order to run this Hello World application, we must first compile it using EWD. Start a terminal session, switch to the directory /usr/local/gtm/ewd and enter the Python shell:

rob@ubuntu910-mdb:/$ cd /usr/local/gtm/ewdrob@ubuntu910-mdb:/usr/local/gtm/ewd$ pythonPython 2.6.4rc2 (r264rc2:75497, Oct 20 2009, 02:55:11)[GCC 4.4.1] on linux2Type "help", "copyright", "credits" or "license" for more information.>>>

We need to import the ewd.py module:

>>> import ewd

At this point you'll find that you've lost character echo. To restore it, so you can see what you're doing, type in the following:

>>> import subprocess>>> subprocess.call("stty echo",shell=True)

OK now that's done we're ready to go. Compile the application by entering:


2

>>> ewd.compileAll("tutorial")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld.ewd>>>

Now you can run it in a browser by using the URL:

http://[ipAddress]/ewd/tutorial/helloworld.ewd

where ipAddress is the IP Address or domain name allocated to the M/DB Appliance, eg

http://192.168.1.127/ewd/tutorial/helloworld.ewd

You should see the Hello World! Message.


3

http://192.168.1.127/ewd/python_tutorial/helloworld.ewd


Chapter 3: Hello World Mk II

OK well that wasn't particularly spectacular: nothing more than you could have done with a simple static page of HTML, but at least we can see that EWD is working and ready to use.

Let's enhance that simple Hello World application a little and make the text come from what we term a Session variable instead. We'll create the Session variable using a Python function.

In the same directory as before (/usr/ewdapps/tutorial), create a text file named helloworld2.ewd containing the following:

<ewd:config prepagescript="py:tutorial.getHelloworldData"><html><head><title>EWD Python Tutorial: Hello World MkII</title></head><body><p><?= #helloworld ?></p></body></html>

What we've done is to add a pre-page script: a Python function that will be executed before the page is generated and sent to the browser. In this case the function is named getHelloworldData() and will reside in a module named tutorial.py. Notice the other change: instead of the hard-coded text “Hello World!”, we're referencing a variable named helloworld. In this case it's what's known as an EWD Session Variable, denoted by the # prefix, ie <?= #helloworld ?>. The purpose of the pre-page script will be to create that session variable: we'll see how to do that in a minute.

First recompile the tutorial application from your Python shell again. You'll probably find that you've lost character echo again. You can reset it by typing:

subprocess.call("stty echo",shell=True)

Then type:

>>> ewd.compileAll("tutorial")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld.ewd/usr/ewdapps/tutorial/helloworld2.ewd>>>

You'll see that both your pages (helloworld.ewd and helloworld2.ewd) have been compiled.

Of course, before we can run your new version, we have to create that Python module named tutorial.py that will contain the pre-page script function we referenced in our EWD page helloworld2.ewd

So, create a file named tutorial.py containing the following text and save it in the /usr/local/gtm/ewd path:


4

import ewd

def getHelloworldData(sessid): ewd.setSessionValue("helloworld","Hello world, this time from an EWD Session variable!",sessid) return ""

Now try running the application in the browser. Use the URL:

http://[ipAddress]/ewd/tutorial/helloworld2.ewd

This time you should see the text:

Hello world, this time from an EWD Session variable!

Let's take a closer look at this example and examine what happened when we ran it. The small additions we made to our original Hello World page actually introduce quite a few important EWD concepts, so it's worth reading the following section.


5


Chapter 4: Relevant Background Information on EWD

Python EWD Functions

All Python functions used in EWD have the same calling signature: they have a single input parameter sessid that will be passed into it at run-time by EWD. The sessid variable contains the unique EWD-generated Session ID for the user.

The main purpose of Python functions that you'll write for your EWD applications is to move data between your database and the EWD Session. The EWD Session is a pool of data that you can create for the user, and, once created, is automatically persisted inside EWD's GT.M database for the duration of the user's session. The Session ID (sessid) provides the unique pointer to the specific user who is executing the function at the time. Your Python functions manipulate the EWD Session via a set of EWD-provided functions, each of which requires this Session ID as a parameter.

The EWD Session

The user's EWD session is created when he/she invokes an EWD page that is denoted to be a “first page” and is destroyed when one of two things happen:

– the user clicks a link that explicitly terminates the EWD session– the user stops interacting with the application for more than the Session Timeout limit

(which by default is 20 minutes, but can be set to any value you like).

Any data stored in the user's EWD session data storage container (known as the EWD Session) is potentially available for use in any of the pages that you'll present to the user throughout the lifetime of that user's session.

The EWD Session therefore provides a middle tier of data storage between the pages that define what the user will see and the database that ultimately contains the data that the pages will be manipulating.


6

In the EWD model, the role of the designer is cleanly separated from that of the programmer. Indeed the role of the programmer is solely related to moving data from the database to the EWD Session and back again, in addition to back-end validation of data prior to storage.

EWD Separates Design from Programming

In the EWD model, the role of the designer is to design and write the HTML and associated Javascript and CSS coding that describes the behaviour of each page. From the designer's perspective, the only thing that appears to distinguish an EWD application from a set of static web pages is that he/she has access to variable information that resides in the Session and appears to be accessible in his/her pages. How that data got there and how it gets back into a database is largely irrelevant to the designer: that's the role of the programmer.

Conversely, the programmer neither particularly knows nor cares how or where the data that is being moved into the Session will be used in the page(s) that require it. The programmer writes Python functions that are triggered by the designer's pages at the appropriate times. The main tasks of the programmer, therefore are:

• fetching data from the database and placing them in the EWD Session ready for use in one or more pages;

• validating and saving data back into the database, in this case data that has been moved into the EWD Session as a result of, for example, an HTML form being submitted.

This clear separation of the database and its associated schema from the web pages that use and manipulate that data may seem unusual to those used to typical contemporary mainstream web application MVC paradigms: in EWD there is no concept of data binding. This is deliberate and contrary to what might be thought, actually proves remarkably beneficial in many ways that we will see in due course.

We've been describing the programmer and designer as two distinct people, but of course in many


7

cases, they will be one and the same person, as will be the case when you're trying out this tutorial. However in EWD, we can consider the work involved in developing an application to be split into these two roles, whether real or notional. This tutorial will refer to the Designer or Programmer where appropriate, even though you'll be wearing both hats!

The Interface Between Designer and Programmer

Clearly for the EWD model to work, there has to be some meeting point between Designer and Programmer. We've actually seen this in our Hello World MkII page. It was the reference at the top of the page to the Pre-page Script:

<ewd:config prepagescript="py:tutorial.getHelloworldData">

Every EWD page must include an <ewd:config> tag, which, by convention, usually is placed at the top of the page. The <ewd:config> tag is used for a variety of purposes as we will see, but its key use in this example is as the place-holder for the reference to a Python function that will be invoked before the page is generated and sent to the browser.

The Designer does not really need to know what the Pre-page Script does. However, he/she will have determined, during the design of the specific page, that the page requires some variable data that must have originally come from the database. So he/she will usually have a good idea that a Pre-page script is needed to fetch that data and make it available. The actual name of the Python function and the name of the module it resides in will have to be agreed with or determined by the Programmer.

In our example, the “Designer” decided to display the value of a Session Variable named helloworld:

<p><?= #helloworld ?></p>

The Programmer has written a Python function, getHelloworldData() and placed it in a module named tutorial.py. This Python module must reside in the same directory as the GT.M database environment in which EWD is running, in our case /usr/local/gtm/ewd,

Our Python Pre-Page Script Function Revisited

Let's now take another more detailed look at that Python function we used as our Pre-page Script:

import ewd

def getHelloworldData(sessid): ewd.setSessionValue("helloworld","Hello world, this time from an EWD Session variable!",sessid) return ""

At the top of the module we import ewd.py because this provides us with the EWD Session management APIs we'll need to use.

The function getHelloworldData() has a single parameter, sessid, which is the EWD Session ID.


8

The ewd.setSessionValue() function was used to instantiate an EWD Session Variable named helloworld, with the value defined by the second parameter. The third parameter is the EWD Session ID.

The function finally returns a null string. This indicates to EWD that the function ran to completion without error.

In this simple example, the value for the EWD Session Variable was hard-coded as a literal string value, but in a proper application, the value would probably have been retrieved from the database.

However the value is obtained, the result is that after this Pre-page script function has completed, an EWD Session Variable named helloworld will now exist and can therefore be referenced in the page using the syntax:

<?= #helloworld ?>

When the page runs, EWD will substitute the actual value of this EWD Session Variable.

What Database can you use with EWD?

The answer is any database that can be supported by Python! Of course the M/DB Appliance provides you with two that you could use: M/DB which is a SimpleDB clone, and GT.M, a schema-less NoSQL Database. However you can use any other database you wish. EWD itself will know nothing about your database: it only concerns itself with data in the EWD Session.

When you move data into the EWD Session, you're actually making use of a GT.M database, but this all happens behind the scenes. All your access to and manipulation of the EWD Session is done using the EWD Session APIs that are available in the ewd.py module.

The EWD Compiler

The EWD pages that the Designer creates are simply an abstracted description of the pages he/she wants to have delivered to the user's browser. EWD's compiler converts those pages into GT.M native language routines. The M/DB Appliance includes a pre-configured EWD/GT.M environment that you can treat as a “black box” that runs the EWD run-time framework. If you're interested you can examine the routines that are generated from your pages: you'll find them in the /usr/local/gtm/ewd directory with a naming convention of ewdWL[applicationName][pageName].m.

We've already seen how EWD's compiler can be invoked from the Python shell to compile all pages in an application directory. You can also compile individual pages:

>>> ewd.compilePage("tutorial","helloworld2")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld2.ewd>>>


9

There are two further ways of compiling pages:

• using the GT.M shell• using EWD's web portal application.

Using the GT.M Shell

The GT.M shell is similar to the Python shell, but you'll use GT.M's native language commands instead of Python ones. You can read about this language elsewhere: here we'll just mention the commands you'll need for this tutorial.

To start the GT.M shell:

rob@ubuntu910-mdb:~$ cd /usr/local/gtm/ewdrob@ubuntu910-mdb:/usr/local/gtm/ewd$ $gtm

GTM>

To exit the GT.M shell, type H or h followed by Enter:

GTM>hrob@ubuntu910-mdb:/usr/local/gtm/ewd$

From the GT.M shell you can compile all the pages in an EWD Application directory as follows:

GTM>d compileAll^%zewdAPI("tutorial")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld.ewd/usr/ewdapps/tutorial/helloworld2.ewd

GTM>

Or you can compile a single page in an EWD Application:

GTM>d compilePage^%zewdAPI("tutorial","helloworld2")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld2.ewd

GTM>

You'll find that the GT.M shell provided command-line recall: to repeat a previous command just press the up-arrow key and press Enter. This makes the GT.M shell very convenient when you're developing a page and need to repeatedly edit and re-compile it.


10

The EWD Web Portal

The M/DB Appliance includes a pre-built EWD Ajax application that provides a web-based portal application for managing many of the day-to-day operations surrounding an EWD environment. This application, named ewdMgr, is also useful in that it demonstrates many of EWD's advanced Ajax capabilities. You'll find the source EWD pages for it in the /usr/ewdapps/ewdMgr directory, but you'll notice that the pre-page and other scripts used by ewdMgr are not written in Python but use GT.M's native language instead. However, there is nothing done in these scripts that couldn't also be done using Python.

To start the ewdMgr application, use the following URL in your browser:

http://[ipAddress]/ewd/ewdMgr/gtmHome.ewd

where ipAddress is the IP address or domain name allocated to your M/DB Appliance

Note: if you get a page telling you that you aren't allowed access to this page, you can reset the security as follows:

From the GT.M shell type the following:

GTM>d resetSecurity^%zewdGTM

Now try that URL again, but add a ? at the end to ensure the browser doesn't just return a cached version of the page, ie:

http://[ipAddress]/ewd/ewdMgr/gtmHome.ewd?

You'll find that from the ewdMgr application you can compile/recompile individual pages or entire applications. One of its really useful facilities is that it allows you to easily view the contents of the EWD Session for specified Session IDs: this is an extremely useful debugging tool during development.

Also within the ewdMgr application you'll find a lot of detailed documentation, tutorials etc that you'll find useful as you become more familiar with EWD.

OK that's enough background detail for now. Let's get back to the tutorial and examine the other key mechanism in EWD: page navigation.


11

Chapter 5: Hello World(s) – Page Navigation in EWD

One of the key parts of web applications is navigating from page to page. In EWD you do this by simply referring to another EWD page name as if it was a URL. To demonstrate this, create the following text files and save them as helloworlds1.ewd and helloworlds2.ewd in the /usr/ewdapps/tutorial directory:

helloworlds1.ewd

<ewd:config isFirstPage="true"><html><head><title>EWD Python Tutorial: Hello Worlds Page 1</title></head><body><p>Hello Worlds Page 1</p><div> <a href="helloworlds2.ewd">Go to page 2</a></div></body></html>

helloworlds2.ewd

<ewd:config isFirstPage="false"><html><head><title>EWD Python Tutorial: Hello World Page 2</title></head><body><p>Hello Worlds Page 2</p><div> <a href="helloworlds1.ewd">Back to page 1</a></div></body></html>

Compile these pages using any of the techniques described earlier and try running the application, eg using the GT.M shell:

GTM>d compileAll^%zewdAPI("tutorial")/usr/ewdapps/tutorial/ewdAjaxError.ewd/usr/ewdapps/tutorial/ewdAjaxErrorRedirect.ewd/usr/ewdapps/tutorial/ewdErrorRedirect.ewd/usr/ewdapps/tutorial/helloworld.ewd/usr/ewdapps/tutorial/helloworld2.ewd/usr/ewdapps/tutorial/helloworlds1.ewd/usr/ewdapps/tutorial/helloworlds2.ewd

GTM>


12

The first page of this application is helloworlds1.ewd, so the URL to use is:

http://[ipAddress]/ewd/tutorial/helloworlds1.ewd

where ipAddress is the IP address or domain name allocated to your M/DB Appliance

You should see a link to page 2 which, when you click it switches you to helloworlds2.ewd which, in turn, has a link back to page 1.

Look carefully at the URLs that are actually invoked however. Although we just specified the EWD page names as URLs, they have been converted into highly secure tokenised URLs. EWD's run-time framework has done this for you automatically.

In this example you'll find that it is actually impossible to invoke page 2 of the application except via page 1. Try it for yourself with the URL:

http://[ipAddress]/ewd/tutorial/helloworlds2.ewd

You'll get an error page telling you:

Enterprise Web Developer Error : Illegal attempt to access a page

Look carefully at the <ewd:config> tags of the two pages and you'll see why this happened:

helloworlds1.ewd

<ewd:config isFirstPage="true">

helloworlds2.ewd

<ewd:config isFirstPage="false">

Only EWD pages that are configured as a FirstPage are allowed to be invoked with an untokenised URL pointing directly to the EWD page. So we could invoke the URL to bring up helloworlds1.ewd, but not helloworlds2.ewd.

If an EWD page is not configured as a first page (ie isFirstPage=”false”) then it can only be accessed via a Url that has been tokenised by EWD's run-time framework. Those tokens are randomly-generated strings that are created by and known only by EWD's run-time engine. Furthermore they are re-generated each time a new instance of a page is invoked, so they are impossible to predict. Additionally, simply knowing a valid token doesn't allow someone to arbitrarily navigate to any page they know the name of: the token is tied to a specific page at run-time, so EWD will ensure that a user can only navigate to the pages that the application is designed to allow him/her to see.


13

It is this automated URL tokenisation that makes EWD a very highly secure web application environment, and it is why EWD is the framework of choice for healthcare web applications where confidential personal information needs to be conveyed securely across the web to authorised users only.

However, as far as the Designer is concerned, page navigation is very simple to define: it's just a matter of referring to another EWD page that exists in the same application directory. EWD page references can be used anywhere that a URL would otherwise be specified, including Javascript, eg:

document.location = 'helloworlds2.ewd' ;


14

Chapter 6: Goodbye World: Terminating an EWD Session

In most situations it is quite OK to let EWD sessions terminate by themselves as a result of inactivity by the user. However you can explicitly terminate a user's session by using a special notional page called ewdLogout.ewd.

Edit helloworlds1.ewd as follows:

helloworlds1.ewd

<ewd:config isFirstPage="true"><html><head><title>EWD Python Tutorial: Hello Worlds Page 1</title></head><body><p>Hello Worlds Page 1</p><div> <a href="helloworlds2.ewd">Go to page 2</a></div><div> <a href="ewdLogout.ewd">Quit</a></div></body></html>

Save the page, recompile it and re-run it in your browser. You'll now see the Quit hyperlink. Try clicking it and you should be redirected to the M/DB web portal application.

What's actually happened is two things:

• the original EWD Session will have been terminated. You could check this using Sessions tab in the ewdMgr web portal application.

• You've been automatically redirected to a pre-configured “Home Page”, in this case the web server root which is the default setting in EWD. The M/DB Appliance is pre-configured to redirect to the FirstPage of the M/DB portal application (an EWD application named mdb) which is why this page came up. You can reset the ewdLogout redirection in a number of ways, but for now we'll leave it as the default.

Note that you didn't have to create the ewdLogout.ewd page. It doesn't actually exist as a physical page: it's a notional page that you can reference as a URL anywhere in your EWD pages.

If you use the ewdLogout.ewd page, EWD's run-time framework immediately destroys the user's Session data storage and deactivates the user's Session ID. None of the tokenised URLs from the closed session will work any more: EWD will generate an error page if you attempt to use them.

What about sessions that are allowed to time out? EWD's run-time framework will automatically garbage-collect timed-out Sessions. By default this occurs whenever a user starts a new EWD Session.


15

Chapter 7: Hello Ajax World

So far we've just looked at simple web pages that use the “classic” web paradigm where navigating from one page to the next causes the browser to completely swap one page of HTML with another. Whilst EWD can be used to easily and quickly build web applications that behave in this way, it has a much more sophisticated mechanism available for you that allows you to build complex Ajax applications instead: applications that can provide an almost VB-like event-driven behaviour that is a far cry from the traditional HTML web page paradigm.

Let's first build an example and then examine in more detail how EWD's Ajax framework operates.

Create the following text files and save them in /usr/ewdapps/tutorial using the names shown here:

ajaxworld1.ewd

<ewd:config isFirstPage="true"><html> <head> <title>EWD Python Tutorial: Hello Ajax World</title> <script language="javascript"> function getFragment() { ewd.ajaxRequest("ajaxworld2","ajaxContent") ; } </script> </head> <body> <div>EWD Ajax Demonstration</div> <div id="ajaxContent"> <input type="button" value="Click me!" onClick="getFragment()" /> </div> <hr /> <div>This text will remain in place</div> </body></html>

ajaxworld2.ewd

<ewd:config isFirstPage="false" pageType="ajax">

<h3> Hello Ajax World!</h3>

Compile them and run this application using the URL:

http://[ipAddress]/ewd/tutorial/ajaxworld1.ewd

You should see the first page appear with a button marked “Click me!”. Click the button and see what happens: you should see the button disappear and get replaced with the text “Hello Ajax World!” in a bold font.

If you look at the URL in the browser's location window, you'll see that it hasn't changed: the browser believes that this is still the same page. What's actually happened is that EWD has replaced


16

just part of the page with a fragment of markup. That fragment was what you defined in the EWD page ajaxworld2.ewd.

Let's look more closely at what happened. The button in the main Container Page ajaxworld1.ewd has an Event Handler: the Javascript function getFragment(). This function invokes a special EWD-provided function ewd.ajaxRequest() that will generate an asynchronous request using the browser's XMLHttpRequest (XHR) object to fetch the EWD Fragment named ajaxworld2.ewd. The second parameter of the ewd.ajaxRequest() function defines the TargetId: the ID of the tag whose innerHTML will be replaced with the incoming fragment content.

So when the button is clicked, the Fragment ajaxworld2.ewd is fetched and its content replaces everything inside the <div id=”ajaxContent”> tag. As a result the original button disappears and is replaced with the text “Hello Ajax World!”.

In an EWD Ajax application, the FirstPage is always a complete page of HTML that includes an <html>, <head> and <body> tag. This is known as the Container Page. Everything else thereafter is delivered as Fragments. Fragments are EWD pages that just contain a chunk of markup. Fragments must not contain <html>, <head> or <body> tags, but otherwise are treated as standard EWD pages. A fragment must be denoted by the attribute pageType=”ajax” in its <ewd:config> tag: this instructs the compiler to correctly treat it as a fragment during the compilation process.

The EWD Ajax framework is therefore very simple. It hinges on three things:

• a triggering in-browser event (eg onClick, onMouseOver)• the fragment name to be fetched asynchronously via the XHR• the targetID of the tag whose contents will be replaced by the new incoming fragment

The ewd.ajaxRequest function is processed by the compiler to create a secure, tokenised URL at run-time. Hence the standard EWD security mechanism is applied automatically to Ajax fragments. The Designer just has to specify the fragment name and targetID and EWD will do the rest for you. The result is an incredibly simple-to-use but extremely secure Ajax framework.


17

Chapter 8: Hello Ajax World Mk II

As far as EWD is concerned, Fragments are no different to any other EWD page, so this means that they can have a Pre-page Script. Hence, Fragments can invoke a Python function to retrieve the data they need prior to them being generated and sent to the browser. Let's extend our example by editing ajaxworld2.ewd:

<ewd:config isFirstPage="false" pageType="ajax" prepagescript="py:tutorial.getHelloworldData">

<h3> <?= #helloworld ?></h3>

Recompile this page and refresh the URL in the browser. The button should re-appear, but this time when you press it, the value of the EWD Session Variable helloworld should be displayed!

We've now covered the main basic features of EWD's core framework on which you can quickly and easily build complex Ajax applications. One of the key tricks is to realise that a Fragment can deliver new TargetIDs and associated event handlers into the Container Page, so you can build up an ever more complex user interface on an event by event basis. Furthermore, by replacing a top-level TargetID's content, you can completely replace an entire section of the Container Page at a stroke: perhaps an area that has been built up over a number of preceding events and fragments. As a result you'll find that back-tracking logic that previously would have had to have been designed into the application's logic can be completely dispensed with. EWD Ajax applications are amazingly simple in terms of their design and yet the user experience can be as complex as you like.

You'll find that EWD allows you to break down a very complex User Interface into a large number of very small and simple Fragments, each probably with its own Pre-page script function that allows it to fetch its data, and no one of the Fragments needs to be very complex in its own right.

This leads to two major benefits of EWD:

• large complex UIs can be managed easily as a team effort: the Fragments that make up the UI can be distributed amongst the team of developers;

• since each fragment is small with a limited behaviour, with its Design clearly separated from its Programming, maintenance of the UI becomes straightforward.

A further benefit of EWD is that the Design process can proceed before and independent of any decisions about the application's data model and database requirements. Initial pre-page script functions can be written with hard-coded values assigned to EWD Session Variables to allow the UI to be prototyped and tested without any database at the back-end. The Programmer then only needs to edit the Python functions to replace the hard-coded values with code that moves real data between the database and EWD Session to move the application from prototype to its fully functioning version.

Furthermore, since the EWD Session de-couples the EWD page from the back-end database,


18

changes can be easily made to the front-end (ie the EWD page content) without these changes necessarily having any impact on the back-end database design, and changes can be made to the database data model without these affecting the front-end UI design. Indeed it is possible to completely replace the database used by an EWD application: provided the contents of the EWD Session remains the same, the EWD application will run identically. EWD neither knows nor cares where EWD session content comes from or goes to: that is the sole responsibility of the Programmer.

Next Steps

This concludes Part 1 of this EWD/Python tutorial which hopefully begins to provide a flavour of how EWD works and how to develop Ajax applications with it.

In Part 2 we'll examine how EWD automates HTML form handling and how it links form fields with the EWD Session.


19

Documents

EWD Python Tutorial Part 1