Sessions
Many heitml components require their internal data structures to be available for more than a single page access. In this case session mode must be used to provide this functionality. In most cases however you will never notice that, because RADpage automatically enables session mode when you put a component that requires session mode on a page.
To work properly session mode requires a so called session key to be passed as URL parameter. This means every link from one heitml page to another must include the session key. heitml uses an URL parameter named card for this purpose. This all happens automatically. heitml automatically modifies all a-tags on your pages to include the card parameter.
Care must be taken however, if you use other means to link to your pages, such a client side image maps, HTML-forms, framesets, or scripts. See Sessions for details. You should also be aware, that if a user leaves your site and comes back later, the session key is lost and so is the state of all components used.
As an alternative there is cookie session mode. Cookie session
mode does not have the problems described above. However since many users
switch off cookies in their browsers it can not be used in many
applications. Another drawback is that with cookie session mode you can not
run two independent sessions in two different windows of a single browser. To
use cookie session mode, change the
Session-less Applications
In general application programs need to maintain internal data, which is supported by the heitml session mode. For certain simple applications data structures are small or not required so that it is possible to use URL parameters instead of session mode. Avoiding session mode has advantages, when using the browsers bookmark functions, the browsers back key, when using caching or search engines. To avoid session mode you just need to avoid all components that require session mode. The component reference tells you for each component if it requires session mode or not.Persistent Components
Certain heitml components have a persistent state. Their state stays available during several page displays of a session. A persistent component receives an initial state when it is displayed the first time. The state then stays then same between several page accesses, unless the component receives an event. For example the user pressing a button of the component causes an event as well as an other component sending a message.
A typical example is the dbscroller component. When displayed the first time it queries the database and stores the result. As long as it does not receive an event, it always redisplays the same content when its page is displayed in the browser. It can however receive events from the scroll buttons and so change its state to display another page of the resulting database records. The dbdisplay component on the other hand is not persistent. It just queries the database an shows the result.
At a first glance the difference is hardly visible however things become important when components receive parameters. A dbscroller depending on some form fields works fine. You can send it a message to select all database records that contain a certain value, where the value is contained in the message. The scroller then will query the database and from then on display the result.
Doing the same with a dbdisplay does not work. Because there is no persistent state dbdisplay can not react on events or messages. dbdisplay can still accept dynamic parameters (e.g. by a dbconstrain that uses an expression as value parameter) but it is in your responsibility to provide the parameters whenever necessary, while a dbscroller once triggered always show the same content.
© 1996-2024 H.E.I. All Rights Reserved.
