webspeed tricks and tips

8/10/2019 Webspeed Tricks and Tips

1/44


2/44

Introduction:

This book is written for working programmers. Since these people are busy, and I suspect they are like myself very little time and lots to do, the book will be written with that in

mind. So to keep the content down to under 100 pages, the following is assumed of the reader a familairity of HTML and Javascript (or VBScript).

The book will focus on stateless programming for Webspeed. This is the most inexpensive means of programming regarding licensing issues, and the most typical for web basedprogramming. This volumn will also be interested in setting the basic elements of Webspeed needed to get rolling. Volumn II will work on state-based programming with Webspeed.

Readers who are familiar with HTML 3.2+ and Javascript will benefit quite well. If you do not understand HTML and Javascript, you had better go get a book on that NOW!

Webspeed pretty much does away with all the Progress 4GL statements to format screen layout. In fact, the statements DISPLAY, MESSAGE, and PUT will be used infrequent ly,and the UPDATE, SET, and PROMPT-FOR will never be used for screen input [1].

The Progress 4GL statements most used will be flow control (REPEAT, IF, RUN, PROCEDURE, etc), value manipulation (DEF VAR, DEF BUFFER, ASSIGN, etc), and Database manipulation (FIND, FOR

EACH, SELECT, etc).

Some new functions are made available to handle input from the web. These have names such as GET-VALUE(), GET-FIELD(), and GET-COOKIE(). These functions will be

explained later on the book.

The book does not explain HTML or Javascript, as there are other books that do that.

Almost all the activity that a user would be doing on the browser, whether filling in blanks for a form, or dragging and dropping entities with Netscape 4.0, will need to be done with

javascript and HTML. Granted the p rogrammer can get by on HTML only, but javascript is becoming a major influence to the thin-client paradigm.

Programmers who use Webspeed will probably al so need to become familiar with MS Windows Operating Systems and UNIX Operating Systems. I will tell the reader right now I ama UNIX guy, but most people in the world are on MS Windows machines, so the browsers available on MS Windows that the application will support will need to be tested and that

requires a familiarity with that operating system. In addition, it seems the best HTML editors are for the MS OSs other than SGIs Cosmo application. The hard-core transactions

and web servers will likely be on a UNIX machine, as Windows NT has been showing some growing pains[2]. Hence the application programmer will need to be familiar with how

UNIX works to gain the most benefit.

The book will cover the components of the Webspeed system. It will not explain in detail how to set up or administer webspeed, as that belongs to Progress. But I will include

somethings so that I wished were in the manuals. An overview is included because Webspeed is a new programming paradigm for most Progress programmers.

Special thanks go to Mark Rigney and Mike Emmons for reviewing the manuscript for a sanity check.

About the author:

Scott Auge works for Auge, Emmons, & Ziola, Inc. He lives in Flint, Michigan, but is usually in some part of the country working on a contract for service and manufactur ingoriented information systems to increase strategic and competitive standing for companies. It is best to reach him via [email protected].

Webspeed Tricks and Tips http://www.oehive.org/amduus/FreePublications/TricksandTips.html

2 of 44 5/30/2014 1:06 PMW b d T i k d Ti h // hi / d /F P bli i /T i k dTi h l
mailto:[email protected]:[email protected]://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.htmlmailto:[email protected]://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.html


3/44

Why use Webspeed?

Webspeed is more efficient in terms of computer resources. A browser program often requires much fewer resources in terms of memory and CPU speed than an executable client

application. This can give hardware a longer life time provided the browser is the only appl ication being handled on the machine.

Since the webspeed agents are actually progress clients, they can be better utilized than shared memory clients and networked clients on the same machine. Since multiple users can

ask the client to do something, the memory and cpu space used by the client is better utilized. No more sucking up memory while a logged in user is drinking coffee doing nothing on

the machine. As soon as a client is finished responding to a users browser, it can be asked by another user to do something far more efficient regarding licenses and machine

utilization[3].

Having the source code centralized on the transaction server machines means there is only one or two places that need source code modifications and updates. For user bases of

100s and 1000s, this can reduce program updates drastically!

Webspeed can be used on Progress, Oracle, Sybase, as well as Informix databases. This allows the webspeed application to interface with many legacy systems with a new WWW

interface. The 4GL can be used in place of SQL to increase programmer productivity and to simplify the programming language used (though there will be times when SQL will still

remain a requirement.) Since Webspeed is a transaction server linked to a web interface, web applications can be designed that transparently use the legacy data in existing DBs as

well as create new data in the existing DBs without the user s even being aware of it. With this, web applications may be able to overtake the functionallity of multiple applications

into one unified interface accessable from a centralized location. In short, a web browser could be started up and p rocede to manipulate the data in multiple databases o f multiple

systems within the company all from one point in the users mind no more click this icon on the desktop to reach order entry and that icon on the MS Office toolbar to reach the

manufacturing system. One can even have one point of login ya in, ya in. All systems can become one with the web interface, and yet users can still be delineated based on

security from reaching different sections of the company.

Webspeed uses HTML and Javascript to handle user activities and 4GL to handle database transactions. Using HTML one can design a more interesting screen for the user to work

with. In addition, HTML can transparently transfer the user from one machine to anot her machine without needing to start another program interface or window though one still

has the ability to do so if desired. HTML can be quickly thrown together by the programmers for prototyping to the users. HTML is a powerful means of describing screens.

Javascript will allow the programmers to have actions take place on the client machine. Though not as powerful as a data manipulation language, it can be used to turn fields on and

off in the screen as data is entered into fields that effect the users ability to populate other fields in the same screen. Also it can be used to verify that a field in the screen has

actually been populated when it needs to be populated. Computation can happen on the screen also as the user interacts with the browser before the browser interacts with the

webserver.

One bad point on webspeed is that it is network intensive. If the network is overloaded or badly configured (routing or has 1 or more choke points) then the users may see a delayed

response from the machine.

Basic Outline of Components

in a Webspeed Application

Introduction:

Below is a diagram of the components in a Webspeed application. This is simplified, and will be exponded on later in terms important to a programmer.


3 of 44 5/30/2014 1:06 PMWebspeed Tricks and Tips http://www oehive org/amduus/FreePublications/TricksandTips html
http://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.html


4/44

Figure Simplified Description of Webspeed Components

A description of the workings:

The user of the webspeed application uses a program known as a WWW Browser, or a WWW client. There are three main clients in use today: Netscape Navigator, Microsoft

Internet Explorer and NCSA Mosaic. The browser is a thin-net client that performs rendering of HTML[4]into a human readable interface. The browser also provides rudimentary

IO such as movement of the cursor, mouse clicking, and text entry. The Netscape and Microsoft browsers also understand two scripting languages called Javascript and VBScript.

The browser makes contact with the webserver. A webserver is a third party program (usually Netscapes Enterprise WebServer, Microsofts IIS, or the internet s Apache server.) It is

a program that handles client requests for web pages.

In order for a Webspeed to function , the webserver will need a gateway feature. A gateway feature allows the webserver to execute programs that can create web pages on the fly.

This is how data can be entered into a web page, or content relevent to the users interest can be made programmatically.

Most webservers handle the CGI gateway, but the Netscape servers can have special coding made available to the server thru the NSAPI as can the Microsoft servers can have special

coding made available to the server thru ISAPI. It is thru this gateway a Progress component called a messenger is added to the web server to begin the ability of the web server toexecute Progress programs (which of course can access the Progress DB, or any of the other major DB vendors[5]Progress supports.)

The messenger contacts a process called a broker (also a Progress component) who determines an available agent process (a Progress supplied component), and passes control to that agent.

The agent then executes a Progress .r file, allowing it to interact with the database , and generate the HTML that will be returned to the web browser thru the webserver. One canthink of the agent as the progress client in the usual Progress paradigm, as in fact, it performs the same function as the client in terms of executing code and preparing output for the

browser to use to render the screen.

Since the agents usually are using a different shared memory version than the database servers, a network connect ion inside the machine must be established. If the agents are to be

communicating with a database on another machine, a network based connection will need to be made anyhow.

In order for the agents to execute any code that uses a database, they must talk to a database server process or a data server process (both supplied by Progress).

Quite often the processes are spread across multiple machines. This way inexpensive computing hardware can be used instead of one huge honkin machine. In general, the browser


4 of 44 5/30/2014 1:06 PM Webspeed Tricks and Tips http://www oehive org/amduus/FreePublications/TricksandTips html


5/44

will execute on the users computer, though if the users machine is an X terminal, the browser may be executing on a different computer and the GUI interface is being sent to the X

terminal. The webserver and the messenger processes must always be executing on the same machine. The broker and the agents also usually are executing on the same machine,

though it may be different from all the other machines. The database server process can also be executing on its own machine. So in a very large system, there could be four or more

computers involved. In a smaller system, there could be two computers involved. In general, the system will have three computers involved: Browser computer, web

server/messenger/broker/agent computer and a database computer. Larger systems can handle more users by spreading the processes needed to handle the users across more

hardware.

Sample Configurations

Following the activities thru the system (UNIX):

First the browser uses a DNS server to determine the IP address of the machine named in the URL to be contacted [6].

Next the port specified[7]is tickled and the webserver answers the connect ion. The webserver then parses the URL sent to it and decides if it needs to run a program in the CGI

directory[8]or if it can serve a page directly from a document directory[9].

Should the URL point to a document directory, the server returns the static HTML stored in the file specified.


5 of 44 5/30/2014 1:06 PM Webspeed Tricks and Tips http://www oehive org/amduus/FreePublications/TricksandTips html


6/44

The more interesting part is when the URL means to execute a program on the web server and that program is the messenger component of the Webspeed Transaction server.

That program in the CGI world is a script that sets the environmental varibles WEBSPEEDCNF and DLC that is used by $DLC/cgiip to begin communication with the transaction server portion.

A connection is made between the messenger and an agent handling the broker service that the messenger is asking to be handled. The agent is passed the program name to run[10]

and performs the run according to the default directory or PROPATH it is was instructed to use in startup.

The agent then usually interacts with the database thru a network connection.

Below is a diagram showing the steps involved diagramatically without the DNS entries as the /etc/hosts or \windows\hosts files could be used on an intranet based application.

How to set up a messenger on a different machine than the transaction server (UNIX):

To help seperate the pain of computation, the implementor may want to use a machine to act as the web server and another to handle database transactions. Seperating the processesto multiple machines can reduce the size of the machines needed, and the implementor may even be able to use machines in existing inventory. The more powerful machine should

be made the transaction server, and the less powerful machine can be made the web ser ver.

1. The messenger portion of the Webspeed transaction server will need to be installed on the webserver, and the webserver will need to be made aware of the messenger thru the webserver's

configuration file.

2. Set up the webserver to have a scripts directory

3. Place the wbsp_cgi.sh file into this directory

4. Rename it to something easier to remember in terms of the application.

5. Edit this file, you will want to hardcode the DLC environmental varible environmental varible so unneeded processing is required to find the webspeed.cnf file that will handle


6 of 44 5/30/2014 1:06 PM Webspeed Tricks and Tips http://www.oehive.org/amduus/FreePublications/TricksandTips.html


7/44

this application and messager. (There is a small do loop in the script that searchs a set of directories, this means disk accesses for the messenger on every hit which can slow things

down a tad bit if your a purist.)

6. If the webspeed.cnf file is not in the DLC directory, you will want to hardcode the WEBSPEEDCNF environmental varible to point to the correct webspeed.cnf file[11].

7. Edit the webspeed.cnf file pointed to by the environmental varible WEBSPEEDCNF in the messenger script file in the webservers CGI directory. The entries of most interest will

be:

PortNum 2001 # Service TCP/IP listening port

Location 100 # 200=Local, 100=Remote

AgentMinPort 2002 # Minimum port number for Agents

AgentMaxPort 2202 # Maximum port number for Agents

HostName remotemachine # Name of local or remote hostname

A different webspeed.cnf file, pointed to be the wtb script to start up the broker and agents will have the same information, except for the Loca tion parameter, which will be 200 to state the

webspeed.cnf file refers to a local broker and agent process(s).

PortNum 2001 # Service TCP/IP listening port

Location 200 # 200=Local, 100=Remote

AgentMinPort 2002 # Minimum port number for Agents

AgentMaxPort 2202 # Maximum port number for Agents

HostName remotemachine # Name of local or remote hostname

The port numbers for the webspeed broker and agents should be the same for the given application environment.

Those seven steps pretty much explain how to get two machines talking to each other in regards to messenger-broker-agent communications.

How to set up the transaction server on a machine different from the database server machine:

The following describes the entries and processes related to getting agents and brokers on one machine to talk to a database server on another machine.

p p p g p



8/44

Files and processes involved in getting agents-broker-database server communications....

The broker and agent processes are spawned from the wtb script found in the webspeed DLC/bin directory. These scripts make reference to a webspeed.cnf file that will include the

connection parameters for connection to the remote database.

DefaultDirectory /appl/rel1 # Broker & Agents working directory

AgentParams -p web/objects/web-disp.p -cpstream iso8859-1 -db d1prod -ld dispatch -H aupaix1.fld.rolm.com -S d1prodpost -N TCP -db rolmdbd1 -ld rolmdbd1 -H

aupaix1.fld.rolm.com -S rolmdbd1post -N TCP -db websecurity -ld websecurity -H scraix11 -S websec N TCP -T /tmp

As can be seen, the connection parameters are based on -db, -ld, -H, -S, and -N parameters normal to Progress clients. These parameters mean the following:

-db Physical name of the database

-ld Logical name of the database

-H Host name with the database to be connected to

-S Service used by the network connection - defined in /etc/services

-N Type of network connection (TCP is usual value)

A .pf file can also be used instead of specifying the database connection parameters.

How to set up multiple environments on the same machine:

This is how I prefer to do things, but there is more information within the Webspeed Administration manual. I find the following steps allow you to construct URLS that are a bit

more easier to remember than including the WSbroker=blah in the text.

1. You will want a cgiip script in the cgi directory for each environment. Give each script a name that describes the environment. Within the script, there will be a call to$DLC/cgiip i [brokername]. Yep, you guessed it, put the broker name after the i in the script.

In the webspeed.cnf file used:

2. You will want to set up multiple broker settings, give each broker a name that describes the environment. This can be helpful for remembering what application the broker is for,

and whether the application environment is develop, test, or production. Examples could be cdrdev, cdrtst and cdrprod.

3. Set up different ports for each set of brokers, agents of different brokers can share the same ports. You definately do no t want to mix up the ports for the various brokers in the

p p p g p

http://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.html


9/44

system.

4. Set up the parameters in the webspeed.cnf file as mentioned above or from the explainations in the Progress Webspeed Administration book.

9 of 44 5/30/2014 1:06 PM

http://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.html


10/44

Basic Components in a Webspeed Development Environment

Introduction:

Developing web based applications requires many components and third party tools. Below is a diagram attempting to describe the relationships between the major source files and

the tools. Some of the source files are not needed depending on what method of development used.

Webspeed Development Environment

The programmer or screen designer will layout the screen in an HTML editor(1). It is always best to have the screen laid out before adding the javascripting, 4GL, or Java added.

Then an HTML file(2)is created from the editor.

The Progress programmer then uses Progress Workshop (3)tool to prepare a webobject that will prepare the page with Progress 4GL language.

The next step depends on if the programmer will use the E4GL method of development or the HTML-Mapped method of development. The HTML-Mapping method requires an

offset file(4)and a .w file(5). The E4GL can have a .w file(5)if needed for deployment on another machine, but does not need the offset file (4). The Workshop product can

automatically create these files but note that some of them will merely be skeletal renderings of the file (basically what it takes to get data in and out of the screen but noprocessing.

The Workshop tool is then used to create a Progress .r file (6).

The Progress Transaction Server(7)tool is used to execute the .r file against a given database (should the code state so under the conditions) and then to return the output of the .r file to the browser(8).

10 of 44 5/30/2014 1:06 PM



11/44

The First Step: Developing the Web Page

Introduction:

When coding is ready to begin on a Webspeed application, the fastest way to prepare the webpage is thru the use of an HTML editor. There are many editors available for both UNIX

and MS OSs. The best type of tool to use is one that allows drag and drop of various web page entities, such as buttons, fields, and images.

Developing the web pages also allows the users to actual see a mock up of the applicat ion as it is being developed. The users should be made aware that at times the appl ication will

need much work to be done under the hood even though it may look to be almost finished because it is appearing in a browser. A good explaination might be that it is drawn out like

on electronic paper instead of on solid paper, and has as much functionallity as a screen drawn on paper.

Some tools to use in the MS Environment:

Hotmetal Pro has an editor that I like. Just about the only thing I do not like abou t it is being unable to re-size images by dragging an achor point. If you wish the browser to show a

certain size, ya will need to work the numbers your self.

Another potential tool to use is MS Front Page. This tool is good for developing the intial page, but be aware that it does add some additional comments and tags to communicate

with other Microsoft tools. I fear that this tool is becoming proprietary to Microsoft systems and is slowly evolving away from being useful in other environments.

A third canidate is the HTML editor available from Netscape called Composer. This tool is a bit weak in terms of capability. It is good for general layout, but for more complex tags,

such as forms and the like, it requires the user to enter the actual HTML.

Finally a text editor can be used for people who are hard core HTML authors and have the skills to create HTML pages on the fly without help from a tool.

Some tools in the UNIX Environment:

Often the UNIX vendor will have an HTML editor available for its machine, or will be aware of an editor(s) that will function on the machine.

SGI has the Cosmo suite, that allows the user to develop web pages. This is a very nice editor with drag and drop and is user friendly.

Netscape provides its Composer tool in many UNIX environments, including Sun, Linux, UNIXWare, and Open Desktop, HP-UX among others.

Usually HTML editors are available at various internet sites, as one editor on one version of UNIX is made available on other versions as well. Linux has many HTML editors

available for it for those who prefer a UNIX work station environment.

Some ways to documenting and analyzing web pages:

As you can consider, developing a web based system will require some changes in what information you want to document and how to document it. Below is an example of some of

the notation[12]that could be used to express your ideas about how screens are interconnected and what data is passed between them.

11 of 44 5/30/2014 1:06 PM



12/44

There are three main types of symbols: screens, data arrows, and flow control arrows. Screens would represent the screens that you wish to have a web object generate. It could be

the same web object generating different screens, could be a single web object generating all the screens, though I would think this would be a nightmare.

The screens are named or denoted in some way for reference. They are represented by boxes with a shadow underneath.

Flow between screens by activities of the user is denoted with a special arrow. This helps identify the activities the user could do to move from screen to screen. Examples would be

a button with an onclick event opening a window and page, or more simply a submit button. It could be a hyperlink that would be available to the user, or some types of events that

could be programmed in the clients (read that browsers) scripting language.

Data is passed between the screens, and this tends to be important to us programmers who need to understand what is coming in and what is coming out. Data can be in different

forms when it comes out of a web page, the two most popular being in a cookie and a form field of somekind. In the future it may even be coming from a Java applet.

Since the data is coming in different entities and HTTP methods, that data will have differing properties. For example, it is much easier to reload() [13]a page activated by a GET

than a POST. The data could be encapsulated in a form field, or sent via a cookie. The use of a symbol to denote the encapsulation method of the data can help sort out how the

data is being transferred around in the system of pages. Some denotations I use are ( C ) for cookie, (H) for a hidden field, and a visible form field with (F). Next to the symbol for

how the data is being transferred, I place the name referencing the data in the HTML.

Documenting the Progress 4GL can be a little tricky also, but will probably be more familiar to the users. A separate diagram can be set up to document calls into various routines

with the 4GL:

12 of 44 5/30/2014 1:06 PM



13/44

This diagram shows a screen with calls into multiple modules of Progress 4GL. Two modules are Progress internal procedures contained within an include file that are given certain

arguments to work with. Two modules are external procedures stored in their respective files who are also given values to be worked with.

Between these two diagrams, a lot of information can be provided about the interactio n of pages and of Progress modules that are generating the pages. It may be difficult to separate

the two at first, and in a way they are related. But I usually try to differentiate data passed in Progress syntax at one level, and data passed in HTTP syntax at anothe r level.

Integrating these diagrams into programming documentation seperated out by feature or function can help explain what is happening in the system, and potentially what is can be

optimized. In addition, if customizations are occuring in the system, whether in the form of maintenance or in feature modification, the consequence of changes can be be tter

determined.

A sample outline for a specification document is given below:

Business Scenerio

- Describe what the program or feature is attempting to do within the organization

- Who the players are

- What process the person using the application will be in

- Where they will be getting data to place into the screen

- Who they will be giving their data to when they are finished manipulating it

User Interaction

- Give a screen layout

- If buttons on the screen, then say what they are going to do

- Screen field validations

System Interaction

- The not so obvious stuff such as database triggers involved

- Program Names that will be created or re-used

- What is going to happen on all the tables involved within the system

13 of 44 5/30/2014 1:06 PM



14/44

- What screen field lands in what tables in what conditions

- What screens are interacted with and data passed between

Database Tables

- Which ones are used

- Which ones are created

- Fields, Indexes, etc.

Note that you documenting system should be able to handle keyword searching or somekind of indexing for easy referening.

Could be MS WORD with keywords for the document. Then set up keywords for questions you will want to ask:

- Tables used by other programs (to make sure something else doesnt get broken)

- Other Validations for the data

- Programs used (for feature interaction)

14 of 44 5/30/2014 1:06 PM



15/44

General New Features in

Progress 4GL for Webspeed

Introduction:

As can probably be guessed now, the usual 4GL statements associated with interacting with the user are rarely relevent[14]. In the web paradigm, a browser takes the place of the

GUI front end for an application. The following chapter explains the general programming functions the programmer will need to be aware of to create web objects executing near or

at the back-end of the process chain to implement a webspeed application.

If the HTML is used to gain and store values for values, how do I get them from the HTML into the 4GL?

We know that HTML provides the information to the browser on how to render the pages: where to put words, diagrams, and input fields. Some examples of instructions to abrowser are:

will create a button on the page, label it with OK and name the button (for internal reference from javascript and the 4GL as we will see in a bit) as userbutton. Note the entire

instruction in HTML, no 4GL has been used yet. In essence, we have created an HTML varible, and named it userbutton. We have instructed the browser to render values of the

varible on a button on the web page.

Another more interesting HTML widget would be the text field. An example coding for a text field is given below:

This would create a 30 character wide (but usually able to hold more than thirty characters think of it as a fill-in widget in the 4GL) entry space for the user to type some string of

characters into. Here we have created a varible named firstname and issued instructions to the browser to render it as a textual field.

So then, how do we get the value from the HTML varibles into the 4GL varibles? By the use of a special function made available in the Workshop product. It is called:

GET-VALUE()

This function will return a string representing the entry performed by the user on a form on the browser. Its argument is the HTML varible name.

An example would be:

15 of 44 5/30/2014 1:06 PM



16/44

First Name:

which would be the HTML used to render a screen appearing as:

As can be seen, there is one text box on the screen that the user can use to input a name and one button tosubmit the screen.

To receive the da ta from the browser (which is controlling the user interaction with the program, NOT your 4GL as in previous progress programming), one uses the following:

DEF VAR FirstName AS CHARACTER NO-UNDO.

ASSIGN FirstName = GET-VALUE(firstname).

These two 4GL statements will define a varible to move the contents of the HTML varible firstname into the 4GL varible FirstName. How to mix the 4GL and the HTML together

depends on which development method is used: HTML-Mapping, or E4GL scripting.

There are additional functions available to nab the values of types of widgets in an HTML page, see your Webspeed Programmers guide for more information on this.

In addition to what is seen on the screen, there is a special means of storing data on the browser called a cookie. A cookie can be stored on a browser during a given unit of time, oras long as the browser is open and then destroyed. Cookies are an excellent means of storing information about who is logged on to the appl ication for application security. More on

that follows.

16 of 44 5/30/2014 1:06 PM



17/44

The means to get a cookie set on the browser is by using the SET-COOKIE() function[15].

To read a cookie one uses the GET-COOKIE() function.

Note that al l values passed between the HTML and the 4GL are in the data type character. If integers are passed in from the HTML, they will come into the Progress code as

CHARACTER. Same for dates, logicals, and other data types.

An example of how to handle potential trouble is via:

DEF VAR a AS INTEGER NO-UNDO.

{error.i}

ASSIGN a = INTEGER (GET-VALUE (thenumber)) NO-ERROR.

IF SESSION:ERROR THEN RUN handletheerror({&BADINTEGER}).

17 of 44 5/30/2014 1:06 PM



18/44

Developing with the E4GL method

Introduction:

The E4GL method is the fastest method to learn if the programmer is already familiar with web based programming. It involves using special HTML markers to note where the 4GL

code is. It is a convenient way to combine HTML, Javascript, VBScript, and 4GL code together into one source file, that way all the peices to the puzzle are made available

immediately to the programmer.

The term E4GL stands for Embedded 4 thGeneration Language.

About the Method:

E4GL is directly embedded in a program that appears more like a static HTML page, than a program. But as we will see later, the page is manipulated by a tool cal led Workshopavailable from Progress to convert the page into a progress program.

Embedding is done via two ways, one is a special comment tag as follows:

Progress 4GL code

and the other tag more familiar to HTML authors and Javascript/VBScript programmers:

Progress 4GL code

In addition, the accent grave or back tic () as it is known is used in special cases within the HTML or Javascript making up a webpage. This tic is used to outpu t values of a varible,or any 4GL expression that returns a value. For example, the following code outputs a textbox with a default value derived from the varible textdefault:

Some other HTML

DEF VAR textdefault AS CHARACTER NO-UNDO.

One can see in the browser a text box whose value is set to the value of textdefault in the Progress 4GL language.

Now the question is probably coming up on how do we compile this HTML file into a Progress executable. The WebSpeed Workshop will be required to go into this next step,

unless a third party converter is used[16].

What workshop does in short is create a STREAM WebStream that is for output. It then puts PUT STREAM WebStream[17]in front of all the HTML statements quoting the

18 of 44 5/30/2014 1:06 PM



19/44

statements with single quotes in the HTML file. If this converter encounters the special tags, it stops putting the PUT STREAM WebStream statement in front of the lines and leaves

them alone creating a pure Progress source file.

So the line:

will be turned by the converter into:

&{OUT} .

Which when the Preprocessor is finished with it comes out effectively as:

PUT STREAM WebStream .

So as one can see, the WebSpeed Workshop, when creating .ws or .rs from HTML pages creates PUT statements that will output HTML (and javascript or VBScript) to stdout (in UNIX terms) that ispassed directly by all the components between the agent and the browser.

Those parts delimited by the special tags are left alone, because they are already Progress 4GL statements. Placement of the Progress 4GL statements in the E4GL style is very

important in the HTML file. Because the execution of the program goes top down with its processing the programmer will always want their HTML PUT statements to be at the

end. If the programmer has their HTML at the top, and processing of varibles and the like at the bottom, the HTML will not have the correct values because it was output before the

values where computed.

In general, the following outline is best for E4GL programs:

1. Varible Definitions

2. Populate varibles

3. Perform record processing

4. HTML code

5. Internal Procedures

Below is a simple program that will create a record using the outline as specified above:


20/44

Customer.Name = CustomerName

Customer.Number = CustomerNumber.

END. /* CustomerName populated */

-->

Customer Name:

Customer Num :

Documenting it under the above mentioned diagrammic method would appear as:

And viewing the screen would appear as:

20 of 44 5/30/2014 1:06 PM



21/44

In general, the programmer will always want the HTML to be the last thing in the main program procedure. The entirety of the HTML can be encapsulated into an internal pr ocedure

that is called from the program. This can allow better control as to when the HTML is going to be output. In fact, the same program could output an entirely different page based on

processing by calling one internal p rocedure with the HTML in it versus another internal procedure with HTML in it.

So, how does this program work?

Here, an understanding of how the Browser and the Web Server interact comes into play. Initally the browser will request thru an URL that this program be executed. On this initial

connection, the REQUEST_METHOD is GET.

1. The program will receive no input, causing the GET-VALUE() functions to return nothing.

2. Some processing shows up where it is determined if any input was sent or not and the creation of a record is based upon this decision.

3. After that, the results are output to the browser, which is pretty much the empty form.

4. The user will enter some information and press the OK button causing a submit to occur using the POST method. Since the ACTION in the form is not defined, the browser will

call for the same URL as used in the GET and pass information along to the program.5. This time, the GET-VALUE()s in the program will receive some data firing the IF and a record will be created, where the output will refect that because of the existance of a customer number.

It must be remembered that the program is executed twice! Once when it is first entered and second when the OK button is pressed. Based on the values available to the p rogram

from the GET-VALUE() is what really drives the activity of the program. It is stateless and thereby started up and shut down with each request from the browser. One can think of it

as starting up a client session and getting some output on the screen. Then kill the connection. At this point the browser takes over allowing editing of the fields. The user presses

OK, and the browser recognizing the submit will again establish a client session to the database and execute a program[18].

So a continous connection is not in the plan for this particular program.

Coding for HTML elements:

Text Box

21 of 44 5/30/2014 1:06 PM

T b h i li h d l If h i h d f l l h P 4GL h h ld h d li i h ibl i 4GL



22/44

Text boxes are among the simplist to hand le. If the user wishes to default a value thru Progress 4GL, then the programmer would use the accent graves to delimit the varible in 4GL

from the HTML.

Button

Buttons dont really do anything unless they are a type of submit or reset. Else, to get the button to be functional , javascript or vbscript will need to be used.

Submit

These buttons do the brunt of the work when activities on the server side need to be performed. This can be the creation, modification, and deletion of records in the database, or for

changing state information used within the program.

Radio

Radio widgets are good for this or this or this but only one of em buddy situations . Only one out of a group can be checked at a time.

By having the same name, the buttons become dependent on each other. This way when the user checks on one, the other will become unchecked. By using the CHECKED

parameter within the tag, the programmer can specify a default value. To determine which widget was checked, do a GET-VALUE(Radio1). A return of Value1 will mean that the

first item was chosen by the user, a return of Value2 means the user overrode the default from the first radio button the the second radio button.

Checkbox

Check boxes are like radio buttons, but have a different look about them. Mostly used in those areas where interdependence between check boxes are not required.

Text Area

The textarea widget allows the programmer the ability to give the user someplace that acts as a small editor.

defaulted text

The above were very small descriptions on the main items a programmer would be using to construct a web application. More information about other input mechinisms and

additional properties of the ones above can be referenced from any HTML reference book.

Keeping business logic out of the HTML:

This is becoming a very important issue for companies, as we are seeing tools for user interfaces propagate in the market there are many many more choices.

In general, the programmers should make an API for nearly every business rule in the company. Really there should be no CREATEs, DELETEs, or database record ASSIGNs in the

E4GL portion of the code. The user interface portion of the application should use RUNs to perform the work of business logic. Business logic APIs will accept only arguments andwill not provide any output or input to the screen (this does not mean it cannot provide a list of ROW Ids or Record Ids for the interface to work with however!)

For example, there could be an order entry screen, and on that screen there are entry lines and a few buttons.

22 of 44 5/30/2014 1:06 PM

We would name all the buttons the same way and they would all be submit buttons (we need to use submit buttons to interact with the web object on the other side of the webserver)



23/44

We would name all the buttons the same way, and they would all be submit buttons (we need to use submit buttons to interact with the web object on the other side of the webserver)

The following code allows the programmer to know what button was pressed to submit the page into the webserver:

DEF VAR ButtonValue AS CHARACTER NO-UNDO.

ASSIGN ButtonValue = GET-VALUE (SubmitButton).

There will be additional code to read in the various values from the form using the GET-VALUE() function:

ASSIGN CustomerNumber = GET-VALUE(customernumber)

Item1 = GET-VALUE (item1).

A call would be made into the API for the button called Create Order:

/* ID Button Pressed the event dispatcher*/

CASE ButtonValue:

WHEN Create THEN RUN ipButtonCreate.

WHEN Cancel THEN RUN ipButtonCancel.

END. /* CASE ButtonValue */

This allows the programmer to become somewhat event oriented, on the event the Create button was pressed, then the ipButtonCreate[19]program will handle that activity of the

user. A general feeling of what happens could be done like this:

/* An event handler */

PROCEDURE ipCreateButton:

ASSIGN var1 = GET-VALUE (var1)

var2 = GET-VALUE (var2).

RUN CreateOrder (INPUT var1, INPUT var2, OUTPUT result).

END. /* PROCEDURE ipCreateButton */

Inside the CreateOrder program would be all the business rules associated with creating an order. If an error occurred because a business rule was broken, then coding would be usedto explain to the user what went wrong. For example, there may be a credit hold on t he customer, or there may not be inventory available for that product. A result would be passed

back from the CreateOrder program and that result would be examined by the event hand ling code to determine what message, if any, needs to be displayed to the customer.

23 of 44 5/30/2014 1:06 PM



24/44

Coding Architecture for Sepera ting Business Logic from UI in Webspeed E4GL applications

Note, that GET-VALUE must be used in a program with {e4gl.i} included at the top, else it will not be defined for use. So in these APIs which are .p files, the programmer will not

be able to use GET-VALUE because it will not be defined in that program. The recommended way of getting information on an event spawned execution, is to perform this in an

internal procedure. The internal procedure would act as the wrapper between the interface and the API.



25/44

Developing with the HTML-Mapped method

Author's note: I have stopped developing this chapter of the book because I do not believe i n the HTML-Mapped method of development in Webspeed. It is di fficult to use,

creates larger .r files than the E4GL method, requires the distribution of three files (.r, .off, html) instead of one .r, is slower due to parsing of .html and .off file s, more fragile to

html changes, and generally requires more development time than the E4GL method of coding.

Introduction:

This second method of development will probably be more familiar to Progress programmers as there is little to no work done on the HTML file.

Using this method requires heavy use of the Workshop product as it creates a lot of code for the programmer getting values into and out of the HTML form.

One of the bad points of this method is that it requires parsing the HTML file nearly everytime the program associated with it is run. In addition, coding a program in E4GL took

significantly fewer lines of code to write than in the HTML-Mapped method, resulting in a smaller and assumingly faster .r file. In fact, one test with the exact same functionallity

showed that the E4GL program compiled to a 17KB .r while the HTML-Mapped program compiled to a 38KB .r file.

In addition, the HTML and .off files need to be sent along with the .w files. While the .w files can be encrypted, the html and the .off files cannot be encrypted and ca n be

manipulated by the user. Adding a field to the HTML file will cause an error and requires a new offset file and a re-compile of the .w to work properly.

With E4GL, only the .w files need to be sent in encrypted form and compiled to be useable on a customers site.

About the method:

Use a HTML Editor to create the HTML Page.

Use the Workshop to create an offset file.

Use the Workshop to map the fields from the form, to varibles or fields in the CGI Wrapper.

Save the CGI Wrapper file (it will be a .w)

Edit the CGI Wrapper with the business logic.

Components of interest in an HTML-Mapped .w file:

WEB-FILE

This is a preprocessor definition that identifies the HTML file to map to and to use to format the output of the wrapper program.

ENABLED-OBJECTS

This preprocessor definiton identifies fields that will be editable in the browser.

DISPLAYED-OBJECTS

This preprocessor identifies the fields in the web frame that will be displayed, ie, used to replace the fields on the HTML form shown in the browser.

Local Varible Definitions[20]

For fields that do not directly effect a database record, local varible definitions are created. These are the varibles as defined in the HTML-Mapping phase in the Workshop.

Web-Frame Definition

25 of 44 5/30/2014 1:06 PM

This will act as the screen buffer for those familiar with such an entity. There really is not a screen buffer in the Webspeed world, as the program really is not interacting with the



26/44

This will act as the screen buffer for those familiar with such an entity. There really is not a screen buffer in the Webspeed world, as the program really is not interacting with the

screen. But it is a convenience for those familiar with using a screen buffer for various activities.

RUN web/support/rdoffr.p

This pretty much makes sure the fields in the offset file created via the Workshop match what is in the HTML file.

RUN htm-associate IN THIS PROCEDURE ()

This procedure associates the form fields name, the varible or buffer field, and a ha ndle into the screen buffer defined in the Web-Frame. This where all the values are glued together.

PROCEDURE output-header

This is where the user will set cookies or other information before the browser starts to receive HTML.

PROCEDURE process-web-request

This is the procedure that defines the heart of the business logic in the application. There are two main parts, one part for handling a GET and one part for handling a POST. A GET

will usually be the first time the screen is brought up by the user, and so it is useful to place default values into fields that the user may be editing, as well as prepare hidden fields

that the user may be using to keep state information.

For a POST REQUEST_METHOD:

RUN dispatch in THIS-PROCEDURE (input-fields:U).

This function will take fields and values from the URL and set them into the Web-Frame as defined in the htm-associate procedure.

RUN dispatch in THIS-PROCEDURE (assign-fields:U).

For those fields that have been manipulated in the form buffer, a movement from the buffer into the database occurs.

RUN dispatch in THIS-PROCEDURE (display-fields:U).

This allows the user to manipulate the form buffer again for values that should be displayed.

RUN dispatch in THIS-PROCEDURE (enable-fields:U).

Running this procedure identifies the fields that should be enabled for user interact ion. If you wish some fields to become inactive, Ie, display, but not allow the user to change the

value, the programmer should enter a DISABLE statement after a call to this program.

RUN dispatch in THIS-PROCEDURE (output-fields:U).

This is where the screen is rendered to the browser with the values from the form buffer entered into the fields and the fields made interactive or not interactive.

For a GET REQUEST_METHOD:

RUN dispatch in THIS-PROCEDURE (display-fields:U).

See display-fields in the POST REQUEST_METHOD.

RUN dispatch in THIS-PROCEDURE (enable-fields:U).

See enable-fields in the POST REQUEST-METHOD.

RUN dispatch in THIS-PROCEDURE (output-fields:U).

See output-fields in the POST REQUEST-METHOD.



27/44

Deploying your webspeed application:

Tips and Tricks in Webspeed

Introduction:

A lot of the tricks achieved are really in the HTML and the Javascript/VBScript used in the application. The 4GL really just manipulates the database in the system.

How to get agents to handle different databases:

You want the webspeed environment to handle different databases. This is done by having a different brokering service.

Looking inside the webspeed configuration file, one

Since I usually use CGI as the interface into the web server, to create access into the given database is by running a different cgiip. Here is what I do, I have two databases: one

handles customer orders, and one handles customers support questions.

Copy the wspd_cgi.sh to orders and to support. Inside orders, I would set cgiip i WSbroker where Wsbroker handles connections to the orders database. Inside support I would set

cgiip I Wsbroker2 where Wsbroker2 handles connections to the support database.

Hence the URL the user would see would read something like:

http://machinename/online/orders/login.html

for the orders submission and lookup, and

http://machinename/online/support/login.html

for the support submissions the customer might have.

Both orders and support would reference the same webspeed.cnf file. Inside the webspeed.cnf file I would set up a set of Messenger/Broker ports for the WSbroker connections to

the databases and another different set of Messenger/Broker ports for the WSbroker2 connections.

Starting up the support system would entail:

1) Starting the databases needed by the transaction server

2) Entering wtb i WSbroker2

Starting up the order system would entail:

1) Starting the databases needed by the transaction server

2) Entering wtb i WSbroker

To check the status of the systems would use the commands:

wtbman q i WSbroker

for the order system and

wtbman q i WSbroker2

for the support system.

To shutdown the transaction server for a given system would use the following commands:

27 of 44 5/30/2014 1:06 PM

wtbman e i WSbroker

http://machinename/online/orders/login.htmlhttp://machinename/online/support/login.htmlhttp://machinename/online/support/login.htmlhttp://machinename/online/orders/login.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.htmlhttp://www.oehive.org/amduus/FreePublications/TricksandTips.html


28/44

for the order system and

wtbman e i WSbroker2

for the support system.

Laying out the files for webspeed system:

This is generally a UNIX centric layout for applications, but something like it can be done with MS OSs.

/appl

This is usually the central trunk for the tree that will contain the components of an application. If multiple applications are involved in a system, then a further break down may bedesired.

/appl/db

Keeping the database in a close place next the rest of the application in the system can be a much more clean and clear explanation of where to find data for an application. One may

want to further subdivide the /appl/db tree into /appl/db/devlp for development versions of the database, /appl/db/prod for the production databases and /appl/db/qa for the qa

database.

As can be expected, the implementor will probably want to keep the database on a separate drive than the source code. Most UNIX systems will allow you to mount a hard drive to

a directory in the middle of the directories of another hard drive, thus looking like the directory is all togetther. This can help in content ion and changing hard drives out to bigger

drives without needing to reconfigure the scripts and such used to connect and interact with the database.

If you have logical volumns, which can make a couple of drives look like one, I wont even go further as you should already have an idea of what I am talking about.

/appl/bin

Usually the startup and shutdown scripts are stored here for a given environment. You will need a startup and shutdown script for the db (if the db is on the same machine as the

transaction server) as well as a startup and shutdown script for the transaction server portion of webspeed.

If you are managing multiple applications with Webspeed you will probably want separate scripts for each application. Then include those scripts in calls from a superscript if so

desired. Be aware that the super script that does everything may freeze up because of some un expected event that may not relate to any of the other applications the script is

suppose to hand le. So keeping the scripts separate allows the administer to get other applications running in case one application causes trouble.

/appl/src

As you may guess, I usually keep the source for the application in this area. It could be encrypted or .r source.

/appl/static

Webspeed applications have a new component to them, and that is the use of icons and graphics within the application that can be directly served by the web server without any

intervention of the Webspeed application. I generally make a rule in the webservers configuration to map the directory of an url into this directory[21].

Use relative URLs in your application:

Only use relative URLs in application unless one must hyperlink to another machine th an what is being used. Using SCRIPT_PATH and other such available varibles may be

tempting, but having the machine within a fire wall can cause trouble.

For example, the customer did not want the web server and the messengers to be outsid e the fire wall. To solve this problem, they used the fire wall softwares ability to translate IP

addresses into another IP address to get access to the internal machine. In other words, the machine to the internet looked like machine1.a.com, but the machine thought its namewas machine.b.com as the internal domain was different from the external connect ion domain. Of course, the varibles were giving the internal name of the machine, and not what it

28 of 44 5/30/2014 1:06 PM

looked like outside of the firewall thus the URLs supplied the machine were giving the wrong name and the internet users could not find that machine. Some tricks with DNS and



29/44

aliasing managed to save time re-programming, but it still was a bit of a hocky way to do things.

Design the pages before entering E4GL coding:

I have found that designing a page up front with Front Page or Hot Metal Pro can help the customer to see what things are going to look like before programming needs to be done.

These layouts can be provided to them with sample data in the layout allowing them to explain modifications that need to be done before actual programming begins.

Once programming has begin, you will likely not want to return to the HTML editor as most of them totally trash the formatting of your 4GL coding after you enter it into the file.

So having the layout agreed upon before coding can save a lot of time, and explaination.

How to get agents to handle a PROPATH:

The agents may be asked to handle working two application, which are differentiated by the broker service they are providing. In this way, the agents can actually handle two

different applications at the same time with different database connection (isnt that rocking!)

To make the agents aware of the different directories of source code can be achieved by two means.

One is to have the default working directory[22]for the set of agents started under one broker service to be set to an application directory, and the other broker service to have a

different default working directory.

Another is to make a copy of the wtb command found in the bin directory of the DLC the transaction server was installed under. The wtb command is actually a script describing

where to find the executables and webspeed configuration files for starting the transaction server under. By copying these files and adding a notation for PROPATH, all the agents

started with that script will be aware of the PROPATH and use them like the cl ient versions of Progress.[23]

Some examples can be:

To start the orders transaction server:

#!/sbin/ksh

# start orders transaction server

PROPATH=$PROPATH:/appl/orders/custom:/appl/orders/src

wtb i OrderBrkr

and the script to start the agents for the support transaction could be:

#!/sbin/ksh

# start support transaction server

PROPATH=$PROPATH:/appl/support/custom:/appl/support/src

wtb i SupportBrkr

Use surrogate keys:

Surrogate keys is a database architecture technique that can help reduce the number o f record changes that occur when the value of a relational field is changed. In addition, it can

help reduce table size in databases for a common relation thru-out the database table architecture by the elimination of a column.

For example the table:

Header:

Code

29 of 44 5/30/2014 1:06 PM

Description



30/44

Is related to the table Detail via Code:

Detail:

Code

IsGood

such that a change on the field Code of a record in Header requires a change on the field Code of a record in Detail.

Example Data for Header Table:

Code Description

a A Description

b B Description

c C Description

d D Description

Example Data for Detail Table:

Code IsGood

a 1

a 2

a 1

a 3a 4

b 1

c 1

We can see from this example, that if the Header record whose code is changed from a into say t, then there are five additional record changes that need to happen in the Detail table, for a total of 6

database changes needed.

If Detail is hundreds of records all relating to a Header record via code, then hundrends of record changes need to be propagated thru the database (in the Detail table and any others

that may use Code from Header as relational information). This can definately effect the speed at which an agent may respond to a transaction, and can cause additional work on the

database manager side that propagates into disk writes and reads and we know how those can slow things down.

So the way to reduce the number of changes is by implementing something called a surrogate key. By adding an integer field into the tables:

Header

Code

HeaderSurrogate

Description

Detail

HeaderSurrogate

IsGood

30 of 44 5/30/2014 1:06 PM

The relation becomes based on the Surrogate key. The data for the surrogate can come from a database sequence named for that particular relation, such as headersurrkey. The

database then looks like this:



31/44

database then looks like this:

Example Data for Header Table:

Code Description HeaderSurrogate

a A Description 1

b B Description 2

c C Description 3

d D Description 4

Example Data for Detail Table:

HeaderSurrogate IsGood

1 1

1 2

1 1

1 3

1 4

2 1

3 1

We can then use the surrogate key to relate by and not the code. So a change of the field code in the table Header from an a to a t will require only one record change, the

Header record and none of the Detail records. They will be implicitly changed by the relation back into the Header record by the HeaderSurrogate field.

One the outset, it may appear that some additional coding may be required to find tables that could be related to the Detail record, but by making these records also relate by the surrogate key, this is

removed.

FIND Header WHERE

HEADER.Code = a

NO-LOCK NO-ERROR.

FOR EACH Detail WHERE

Detail.HeaderSurrogate = Header.HeaderSurrogate ...

FOR EACH CreditDetail WHERE

CreditDetail.HeaderSurrogate = Detail.HeaderSurrogate AND

CreditDetail.IsTax = ....

/* Since Code is no longer in CreditDetail, need to */

/* translate for the user. */

DISPLAY Header.Code CreditDetail.Qty ....

END. /* FOR EACH CreditDetail */

31 of 44 5/30/2014 1:06 PM

END. /* FOR EACH Detail */



32/44

In addition, the use of surrogate keys may be able to reduce the number of columns needed in a table to create a relation. This is in the case of records that are directly related to

other records that need two or more columns to be related.

An example across three tables of fields (a, b, c), (a, b, d) and (a, b, e) would be:

a b c

1 1 t1

2 1 t2

1 2 t3

a b d

1 1 d1

2 1 d2

1 2 d3

a b e

1 1 e1

2 1 e2

1 2 e3

By making the table of (a, b, c) the relational header, one can set up a surrogate key, s, for the relations (a, b) on the other tables, with a single column, transforming the tables into:

a b c s

1 1 t1 1

2 1 t2 2

1 2 t3 3s d

1 d1

2 d2

3 d3

s e

1 e1

2 e2

3 e3

So in effect, we have removed one column of data the database needs to store, and potentially index (as indices are on the relational fields most of the time!) These space and time

savings can be brought across multiple tables if the relation described in the surrogate key is used in multiple tables.

The con to this, is on the outset, it appears the database is heavily de-normalized. There is still some commotion among the people I know if this truthfully is de-normailizing thedatabase architecture or not, as there still are pure relations involved, just at a more abstracted level. [24]

Also, the number of records in a table is limited to the largest integer Progress is capable of generating and storing. So its use may be limited if you are expecting the table to contain

more than 2 billion (thats US billions or 2 x 10 9) records. Using Decimal can make the number of records reach into 50 digits according to Progress Limits.

In addition, additional coding may be needed to translate a code the user may enter into the surrogate key by finding the appropriate header record. A small price to pay in large

databases.

If the relation is unique, the surrogate key should be unique. If the relation is not unique, then a buffer find may be required to get the original surrogate key value for that

combination from a previous CREATE for a new CREATE or MODIFY of a record using that combination.

32 of 44 5/30/2014 1:06 PM

Setting up a security algorithm:

F i h d b f l l f



33/44

For security, there needs to be four levels of access.

The following diagram describes the relations visually.

At the lowest level called 1, is the URL. This would be each and every web page we want to handle with the security feature. This level answers if someone bookmarks or attempts

to enter the URL into the browser, whether or not if they have any business in the URL.

At the next level called 2, we group sets of URLs into features to handle those sequences of screens that make up some peice of functionallity in the application. These features

within a given application can have security set for various users, so as those users can have access to all the URLs in that feature. Some users may have access to a feature (that is

actually a collect ion of URLS) or they may not have access to the feature. However, one set of users could have access to another set of URLs thru a different Feature, thereby givingthe application some security over who can go into what feature within the application.

Additional resistance to users accessing an URL can be added at a higher level named 3, by collecting features (which are a collection of URLS) into applications. Access to wide

sets of URLs can be denied to a user if they do not have access to the application or any of the lower levels. Applications are made up of features, which in turn are made up ofURLs, and any access given to them in the lower levels will give them access to that level and below of URLs in this scheme of doing things.

Finally, determining the applications available to the User can be stored at the top level called 4.

The following describe the basic tables and fields needed to make the above. They do not provide space for naming urls, features, applicactions or suites. They concentra te on

grouping elements as described above. Implementors will probably want to add additional information or relations to additional information, such a feature description, application

description, and suite description for appearing on a menu of some sort to the user.

TABLE: User

FeatureCode integer Relates to Feature.FeatureCode

URLData character

UserAllowed character

INDEX: Key URLData, UserAllowed

TABLE: Feature

FeatureCode integer

33 of 44 5/30/2014 1:06 PM

ApplicationCode integer Relates to Application.Appl icationCode



34/44


INDEX: Key FeatureCode, UserAllowed

TABLE: Application

ApplicationCode integer

Suite Code integer Relates to SuiteCode


INDEX: Key ApplicationCode, UserAllowed

TABLE: Suite

SuiteCode integer


INDEX: Key SuiteCode, UserAllowed

The algorithm to check user access would be:

First would be a set of inputes. The data needed are the URL visited, which can be the base name of the URL. It should match what the page would call itself. Also needed would

be the visitors name. Right now, that would probably be coming from a cookie. More on that later on in this section.

INPUT URLVisited

INPUT UserName

The first step is to find a level 1 record that would show the given user has access to the URL. If a record with the URL and the user name shows up, then they definatel y have access

to the URL. If not, then we will need to move up the ladder to the next level to det ermine if they have been given access at that point .

Find URL

where URLValue = URLVisited

and UserAllowed = UserName

if available, allow access

If that original record is not found, then we will need to see if we can find a record with the URL and what feature that URL is a part of. Once that is establised we can then move up

to the feature records with the correct feature code. If we cannot find such a record, then the URL probably is not in the security system, and the default in this algorithm is to deny

access. Others may want to default to allowing access.

Find URL

where URLValue = URLVisited

if not available, deny access.

Now that we have a URL record that matches the URL visited and the feature that URL is a part of, we can move up and attempt to find a Feature record with the users name on it and a feature code

matching the feature that URL is a part of.

34 of 44 5/30/2014 1:06 PM

Find Feature

h U All d U N



35/44

where UserAllowed = UserName

and Feature.FeatureCode = URL.FeatureCode

If available, allow access

When we cannot find a feature with the users name on it, we then need to again move up a level by attempting to find a Feature by the URLs feature code. Then use that record to

find out what Application that Feature is a member of. If no such Feature can be found, then simply deny access.

Find Feature

where Feature.FeatureCode = URL.FeatureCode


Once a Feature record is found, we can use its ApplicationCode to locate the Applica tion Record that might be available with the users id on it. If such a record exist s, then we can

allow the user access to the full set of features under the application, as well the full set of urls under that app licationss features.

Find Application

where Application.UserAllowed = UserName

and Application.FeatureCode = Feature.ApplicationCode

If available, allow access

Again if we cannot find the user at the application level, we need to find out what suite the application is under, and if the user has access to the full suite of applications based on an entry in the Suite

table.

Find Application

where Application.FeatureCode = Feature.ApplicationCode


Find Suite

where Suite.SuiteCode = Application.SuiteCode

and UserAllowed = UserName.

if available, allow access.

else deny acess.

To run thru a sample:

URL

URL FeatureCode UserAllowed

inp_order 1 scottauge

Feature

FeatureCode ApplicationCode UserAllowed

35 of 44 5/30/2014 1:06 PM

1 2 markrigney

Application



36/44

Application

ApplicationCode SuiteCode UserAllowed

2 1 mikeemmons

Lets explore what happens when scottauge tries to access the URL inp_order.

The algorithm attempts to find an URL record with scottauge and the URL. In this example data, we see such a record exists, and so the user scottauge would be allowed in to the

page.

When markrigney attempts to access URL inp_order, we can see that no such URL record exists with his name on it, so we need to start moving up levels. The algorithm wouldattempt to find the feature the URL is a member is, in this case 1. Then it would access a feature record with the name markrigney on it, and would allow access to the user.

The user mikeemmons would go thru three such jumps before being allowed access by the algorithm.

If we had a user john doe, which is not mentioned in any of the records, the algorithm would deny john doe access to the page.

This algorithm should be run before any HTML is sent to the browser. This way a RUN statement can be performed that may outpu t another HTML page (like your not authorized

to use this part of the web appl ication.) To do this effectively, the OUTPUT-HEADERS internal procedure should be used.

The E4GL methods OUTPUT-HEADERS internal procedure

Using the E4GL method, a special internal procedure is run before any of the main program is executed. By making a listing of the program, one can see what the architect ure of the

application truely is[25], compared to what one might think it is simply by looking at the coding provided by the applications programmer.

Before any output is sent to the browser, this program is executed. Inside this program, you may want to put your security algorithms and definately your cookie setting code, asstrange things will appear in the browser after the tag is put out (an automatic thing).

In my programs, security is usually always implemented, so I make an include file:

/* security.i include file */

DEFINE OUTPUT-HEADERS:

/* some security based stuff */

/* allow the application programmer to create a local-output-header */

/* to be run after the security is set. */

IF SESSION:GET-SIGNATURE(local-output-headers) BEGINS PROCEDURE THEN RUN local-output-header.

END. /* OUTPUT-HEADERS */

Javascript for active and inactive fields:

New Page 1

36 of 44 5/30/2014 1:06 PM



37/44

// Explore how to make fields active and inactive

// Explore how to determine if fields were changed

// General Theory of Operation:

// Have a set of rules to set varibles describing "activeness" for each input object. Basically,

// onchange()s on input objects will be used to set varibles to describe the "activeness" of other input

// objects. Those objects will have onfocus()s to determine if the user can enter data or

// not.

// Use a set of varibles to determine if an input object should be active,

// initially all input items are active.

var abutton = true;

var aselect = true;

var aradio = true;

var acheckbox = true;

var atexted = true;

var atext = true;

// Have a set of rules to determine if the object is active. Each object

// should have a onfocus() event handler attached to it, to call into this

// function to determine if the input item is active. If not active, blur will

// be applied.

// This is a general function, from here, individual functions determine the activeness

// of an input object. This is so all input objects have one place to go to determine

// activeness. If the object does not have its activeness controlled, then return

// true at all times.

function isactive (objectptr) {

if (objectptr.name == "button") {

if (abutton == false) objectptr.blur();

37 of 44 5/30/2014 1:06 PM

}

else



38/44

else

if (objectptr.name == "select") {

if (aselect == false) objectptr.blur();

}

else

if (objectptr.name == "checkbox") { if (acheckbox == false) objectptr.blur();

}

else

if (objectptr.name == "texted") {

if (atexted == false) objectptr.blur();

}

else

if (objectptr.name == "text") {

if (atext == false) objectptr.blur();

}

return true;

} // isactive()

// This function actually applies rules to if an input object should be

// active or not. This is done by calling from the onchange handler on

// each input object.

function setactive (objectptr) {

alert (objectptr.name);

alert (objectptr.value);

// If the object is the text box, then make the text editor box

// inactive.

if (objectptr.name == "checkbox") {

38 of 44 5/30/2014 1:06 PM

if (objectptr.checked)

atext = false;



39/44

ate t a se;

else

atext = true;

alert("set atext to " + atext);

} // text box was populated

} // setactive()

Javascript for required fields:

39 of 44 5/30/2014 1:06 PM

New Page 1



40/44

// Determine that required fields in the form have been entered

// Function to call on the submit of the form. This should be mentioned

// in the FORM tags event handle onsubmit()

function valreqfld (formptr) {

var noerror = true;

var errormsg = "";

// Here we check if required fields have been entered.

if (formptr.T1.value == "") {

errormsg = errormsg + "T1 is required entry\n";

noerror = false;

}

if (formptr.T3.value == "") {

errormsg = errormsg + "T3 is required entry\n";

noerror = false;

}

if (! noerror) alert (errormsg);

return noerror;

}

40 of 44 5/30/2014 1:06 PM


41/44

name="B2">

Javascript for client level calculations:

New Page 1

// How to set up a calculation between fields and how to make the sum

// fields "read only"

// Note that the function is in the form object which contains the input

// objects that will be used to calculate with.

function calculate () {

document.calc. t3.value = Number(document.calc.t1.value)

+ Number(document.calc.t2.value);

} // calculate

41 of 44 5/30/2014 1:06 PM


webspeed tricks and tips

Documents