Consultor Eletrônico

Status: Verified

GOAL:

How to pass information from one web object to another, either with or without browser interaction in between.

FACT(s) (Environment):

Webspeed 2.x
All Supported Operating Systems

FIX:

The best method depends upon your goals. Certain methods lend themselves better to some application models than others, but this is best determined by the designers of your application.
WebSpeed provides the capability of running an application in a state-aware mode. The state-aware mode requires the "locking" of a WebSpeed Transaction Agent to a specific browse user until either the next request from that browser or a timeout occurs.

If you run in state-aware mode, you eliminate the need to pass information between browser interactions because the agent that runs the application maintains the full application state for a specific user (including any records that are accessed as well as variable values).

(Refer to the WebSpeed Developer's Guide for detailed
discussions about implementing the state-aware mode.)

If you run in state-aware mode, you must have a dedicated agent for your browse (for the duration of the state-aware condition). This might present resource issues, depending upon your application and environment.

The following possibilities might be considered if you want to pass information between Web objects and do not want to run your application in the state-aware mode:

- Cookies.

(commonly used to pass data between Web objects when there
is browser interaction in between):

Cookies cannot be used without this intervening browser
interaction.

The Web server must get the cookie information out to the
browser in order for it to be accessible by any other Web
object on return from the browser. The cookie information is
returned with any request from that browser to a subsequent
Web object.

Significant coding might be required if you use cookies to
communicate large amounts of information. Cookies can hold
approximately 4K of data, represented as Name=Value pairs
delimited by &'s.

Because cookie information can be seen, security might be an
issue, depending on the information you intend to pass in
this manner.

Keep in mind that some browsers can tell the user when they
have received cookies and some users might prefer not to get
them. Also, some users might choose to disable cookie
handling on their browser and your application must be
designed to handle this condition if you use cookies.

- Use of context records.

An efficient way to use cookies is to maintain the
application context information in a database table and pass
the ROWID of the record back to the browser as a cookie.
&nb.sp; When the user responds, you can get the ROWID and access the
context information you stored in that record during the
last application interaction for that user.

A context record might include data such as customer number,
order number, total order value, etc., whatever is needed
within your application to re-instate processing for a
specific user. There may be more initial setup involved in
this approach because you must identify the information to
be stored in the database table and ensure that data is
present at the time it is needed by each Web object.

The advantages of this implementation might include less
coding per object and greater security because the only
cookie information is a ROWID that would be meaningless
outside the context of the application.

- Hidden fields.

Hidden fields can be used in a manner similar to cookies
except they are returned from the browser if the form action
is "POST". Although the information stored in them is not as
accessible if intercepted over the network, it can be viewed
if the browse user chooses to View Source from their
browser.

Again, a single hidden field could be used to hold the ROWID
of a context record in a database as discussed in the
previous point.

- Defining fields with the same name on multiple pages.

Information can be passed from one page to another because
the name=value pairs share the same html element name. It
can be passed without an intervening browser interaction
once the initial data has been submitted.

In addition, you can have those values persist across
interactions. Typically, the form element is visible only on
its initial display in order to allow the browse user to
enter data. That element could then exist as a hidden field
on any subsequent form and be available from input fields or
GetField following a "Post" action.

Once posted, you can access the data multiple times in your
application without going back out to the. browser (for
example, one Web object can access the information and RUN
another Web object that can also access it using GetField or
input-fields).

You might find it convenient to store the ROWID of your
context record in this manner across any number of forms
presented to your browse user.

- Use parameters as documented for the 4GL to pass information without intervening browser interaction.

If you define parameters for a Web object, you cannot access
that Web object directly from a URL. Only the name of a Web
object to run can appear on the URL. The startup procedure,
web-disp.p invokes run-web-object passing the named object
from the URL.

The run-web-object procedure in web-util.p accepts only a
single parameter for the name of the Web object to run.
Therefore, no additional parameters can be passed on the URL
through web-disp.p to the Web object.

- Use global variables.

This solution requires cleaning up the variables before they
release the agent for use by another browse request (because
global variables persist for the duration of the agent
session).

- Information can be appended to the URL and obtained using
GetField in "GET" processing of subsequent Web objects.

When you combine this with use of the parameters for 4GL, you
can, for example, run a procedure that requires parameters
from either a calling Web object or from a URL on a return
from the browser.

The URL would in this case reference a "wrapper" procedure
and would contain Query-String value pairs to be passed as
parameters.

For example:

(a.w is the first Web object in the application and
prompts for customer number. The second procedure, b.w, requires an input parameter of customer number in
order to display a page back to the browser that
contains information about the specified customer.)

Once you identify the desired customer number, you
might want to allow. the re-display of customer
information using an HTML link:

_____

| |

1) ----> Get --> | a.w |

2) <-- HTML <-- | |

3) ---> Post --> |_____| ----> RUN b.w (INPUT cust-num)

(input custnum) |

| Get

v

_____

| |

4) <-- HTML w/link to bb.w -- | b.w | <--------|

|_____| |

|

... |

<intervening processing, still |

maintaining the link somewhere |

in the generated HTML> |

RUN b.w (INPUT INTEGER(custno))

... ______ ^

| | |
R> 5) --> Link to | | |

bb.w?custnum=1 (Get) -> | bb.w | --> GetField

|______| (INPUT custnum,

OUTPUT custno)


So, in the "Get" processing of b.w and subsequent

objects, your application could format a link to a

"wrapper" object, bb.w, as follows:


{&OUT}


"Redisplay customer info".


In the "Get" processing of bb.w:


DEFINE VARIABLE custno AS CHARACTER.

RUN GetField IN web-utilities-hdl (INPUT 'custnum', OUTPUT

custno).

RUN b.w (INTEGER(custno)).


The information appended to the URL is, of course,
totally visible both to the browse user and in transit
to or from the Web Server. However, it is also a very
portable solution.

You might be able to encrypt the data depending on your
Web server..