Kbase 17012: How to Pass Information Between Web Objects
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
9/29/2008 |
|
Status: Verified
GOAL:
How to pass information between Webspeed objects.
GOAL:
How to pass information such as; Cookies, Hidden fields, Parameters, User fields, URL format, Global shared variables, Shared variables, from one part of a web application to another?
GOAL:
How to use Cookies, Hidden fields, User fields, URL format, Global shared variables and Shared variables.
FACT(s) (Environment):
WebSpeed 3.x
All Supported Operating Systems
FIX:
The ways to pass information between web objects are:
- Cookies:
Cookies are maintained by the Web Browser. If your first web page runs a second web page via a LINK, you can use set-cookies to pass information to the .w that is associated with the LINK.
Use set-cookie() from the first web page in an output-header's local procedure. This makes the cookie information available to the second web page, but only after the HTML is run the first time. This may or may not be useful.
Suggested process is to set a user field at the same time so it will be available right away. The reason you would still set the cookie would be to keep the information available longer.
For Example:
setcookie.html and getcookie.w.
Setcookie retrieves information from the URL - password, sets a cookie - cust-num and also uses the set-user-field so that the information passed into the web object is available for use in setcookie right away.
Getcookie is called from a link in setcookie. The cookie is available for use in Getcookie. To demonstrate, run setcookie in your URL as follows:
http://host-name/scripts/Webspeed-Messenger/setcookie.r?password=23
- Hidden fields:
The use of hidden fields is also recommended for passing information from one web program to another. It can be used to pass information to a second web object that is called from the first web object's form action (submit button).
It is required that you have an input form in order to use hidden fields. Example:
sethidd.html and gethidd.html
- Passing parameters:
If you have a web object that calls another .w by use of the RUN statement, it might be possible to pass parameters that .w. However, if you, as the second .w, can also be run directly from the web, you do not want to pass parameters because this would not be supported by a web object.
In this second instance, you want to set user fields (below).
- User fields:
User fields are the recommended approach when you pass information between objects where the browser is not involved. In other words, you are running a second web object directly from the first web object using the RUN statement.
User fields are recommended over shared variables unless you have a lot of information to share and do not want to set many user fields.
Another advantage to user fields is that they disappear after each request so there is no clean up involved as is the cleanup when you use global variables.
Another example of a good use of user fields is when you build a URL with name/value pairs and want to pass a list of items instead of hard coding many name/value pairs (see URL format below for more information on this method). An example:
setuser.html and getuser.html
- URL format:
Passing the information directly as part of the URL is also a suggested method when you run a second web object via a link. URL format can be used to create the URL on the fly. You can also pass information via the URL on the query string by using set-user-field, and either include these user fields in the url format or hard code the name/value pairs when you build the URL.
For Example:
setqstr.html and getqstr.html
- Global shared variables:
Global variables are not recommended. In order to use global variables, you must lock an agent. These variables remain available as long as the agent is available, so this information could be obtained by non-related applications.
These variables last as long as the agent lasts, and therefore you must set the global variables to " " at some point before your application ends (possible in a local-destroy() routine).
There is a lot of overhead a.ssociated with global shared variables.
- Shared variables:
Shared variables are also not recommended unless you have a lot of information to share and do not want to set user fields for each value.
Shared variables can be used in a scenario where one web object calls another web object directly via a RUN statement. If you are accessing a second web object via a link or from a submit button, the browse has no access to the shared information (unlike using cookies)..