Session Parameters - Combining SQL, Oracle Text, XSLT, and Java to Publish Dynamic Web Content

So far, all of our examples about parameters have been of page-private parameters.

These parameters function much like parameters to scripts. Session parameters, on the other hand, exist across invocations of XSQL. Your servlet engine maintains the session on behalf of the XSQL servlet. This has the implication that only servlets will be able to make use of session parameters.

Setting session parameters is quite simple. You set them just like you set cookie parameters. The following XSQL will set a session parameter named enameand one named deptno:

<?xml version=”1.0”?>

<xsql:set-session-param name=”ename” value=”{@r-p-ename}” />

<xsql:set-session-param name=”deptno”>

select deptno from emp where ename=’{@ename}’

</xsql:set-session-param>

</page>

104 Chapter 6

Now, save the file as set-session-param.xsql, and access it with the URL http://localhost/xsql/momnpup/set-session-param.xsql?r-p-ename

=ADAMS&.

If you now go back to the include-request-params.xsqlpage that you cre-ated earlier, you’ll see the output that is shown in Figure 6.5. These parameters will be part of your session until the session ends. Your servlet engine ultimately controls the session itself. It usually continues until the browser window is closed or until some period of inactivity.

If you know that a given XSQL page will only be called within a session, then you can use session parameters instead of having to deal with the complexities of request parameters or page-private parameters. For instance, let’s suppose that you want var-ious kinds of information about a particular employee. You can create a simple form that has an input field named r-p-ename and then set its action to the set-session-param.xsqlpage you created previously. Alternatively, you can just use the URL that you just used.

WA R N I N G Notice that our request parameter, r-p-ename, and our session parameter, ename, have different names, though they refer to the same entity. A session parameter can’t be assigned the value of a request parameter of the same name. (It is legal for parameters of different types to have the same name—the rules for resolving the naming of conflicts are laid out later in this section.)

Figure 6.5 Session parameters and <xsql:include-request-params>.

Now, the ename and the deptno parameters are set for the entire session. If you want a list of everyone in the department, you can do that with a very simple XSQL page:

<?xml version=”1.0”?>

<?xml-stylesheet type=”text/xsl” ?>

<xsql:query>

select * from emp where deptno={@deptno}

</xsql:query>

</page>

Cookies

HTTP cookies try to solve a fundamental problem of HTTP. How do you create state when using a stateless protocol? You saw cookies at work in the previous section. If you look back at Figure 6.5, you’ll see an entry in the cookies element. This cookie is actually the one that is used by the servlet engine to control the session.

The basic mechanism is that a cookie is set on the Web browser. The cookie itself is really just a string. The Web browser stores that cookie in some way on the local machine. That cookie is passed back on subsequent requests. The browser will only pass a cookie back on requests for which the cookie was specifically meant. This means that if www.yahoo.comsets a cookie, there is no way that the cookie will be passed to your Web application, assuming that your Web application isn’t running in the yahoo.com domain. Further, you can restrict cookies so that they are only sent back to certain URLs within your own domain. Cookies can be either session based (i.e., they are erased when the Web browser closes down) or long lived. Long-lived cookies can stay on the browser virtually forever.

When the cookies return, your application is able to assume that the current transac-tion is originating from the same Web browser as previous transactransac-tions. Thus, you are able to maintain state on the server side. This is exactly what the servlet engine does with the cookie that it sets. It attaches all of the session information to that particular cookie on the server side. That single cookie can act as a key to a lot of different infor-mation. When you set cookies manually, you can create the same kind of architecture.

This is the way cookies generally work. However, it is very important to understand that the individual users ultimately have control of whether cookies will work this way for them. Users can set their browser so that they don’t accept cookies, or don’t accept long-lived cookies. They can go in and choose to delete cookies that your application uses. If you depend on cookies for authentication, you may find your users trading their cookies around. When using cookies, it’s important to remember that you can’t depend fully on their full and appropriate use. Cookies certainly make the developer’s life easier. If you can require your users to have cookies enabled on their browser, then you’ll have an easier time designing your application. However, if you can’t, you need to consider ways that your application will degrade gracefully.

106 Chapter 6

With an understanding of the problems of cookies, let’s look at how to use cookies with XSQL. The basic model is the same as with page-private parameters and session parameters, but with some extensions. Let’s cover the basics first. The following XSQL page will set the employee name and the department number as cookies:

<?xml version=”1.0”?>

<xsql:set-cookie name=”ename” value=”{@r-p-ename}” />

<xsql:set-cookie name=”deptno”>

select deptno from emp where ename=’{@ename}’

</xsql:set-cookie>

<xsql:include-request-params />

</page>

Save this as set-cookies.xsql. You can call it with http://localhost/xsql /momnpup/set-cookie-param.xsql?r-p-ename=SMITH&. You can then invoke the include-request-params.xsqlpage that you developed previously and see the results that are shown in Figure 6.6.

Figure 6.6 Setting cookies with XSQL.

An obvious question is, “Why would I want to set cookies manually instead of just using the session?” In most cases, you wouldn’t. Cookies do have one advantage over session parameters: You can request that cookies live past the current session. You are able to do this with the max-ageattribute as follows:

<?xml version=”1.0”?>

<xsql:set-cookie name=”long-living-cookie” max-age=”999999”

value=”To_Life” />

<xsql:set-cookie name=”deptno”>

select deptno from emp where ename=’{@ename}’

</xsql:set-cookie>

<xsql:include-request-params />

</page>

If you invoke this XSQL page, shut down your browser, and then restart it, the cookie will survive. A call to include-request-params.xsql will confirm this. The max-agevalue is in seconds, so in our example, the cookie will live for about 11 days.

You can also control the URLs to which a cookie should be returned. Previously, you learned that your application isn’t going to receive cookies set by www.yahoo.com. In fact, by default, no URL outside of the original directory where XSQL first set the cookie will see it. To demonstrate this, create another directory named test-cookies in the demo directory and copy include-request-params.xsqlin it. When you go to http://localhost/test-cookies/include-request-params.xsql, you won’t see the long-living cookie. Go back to the original include-request -params.xsqlpage, and there you will find it.

For many applications, this is too restrictive. If nothing else, it means that all of your application must be in the same directory or subdirectories. Luckily, you can control this behavior very easily. Using the path attribute of the xsql:set-cookieaction, you can make the cookie generally available to all of the application. This XSQL page sets another cookie that should be available anywhere on your server:

<?xml version=”1.0”?>

<xsql:set-cookie name=”long-living-remote-cookie” value=”To_Life”

path=”/” max-age=”999999”/>

</page>

You can reference cookies just like you can any other parameter by using the {@cookie-name}syntax. You aren’t limited solely to parameters set by XSQL. You can reference any cookies that come your way, including cookies set by other applica-tions in your system.

Dans le document Combining SQL, Oracle Text, XSLT, and Java to Publish Dynamic Web Content Oracle XSQL (Page 125-129)