www.openlinksw.com
docs.openlinksw.com

Book Home

Contents
Preface

Internet Services

WebDAV Server
URIQA Semantic Web Enabler
Mail Delivery & Storage
NNTP Newsgroups
MIME & Internet Messages
FTP Services
VSP Guide
Introduction Simple HTML FORM usage Interacting with the Database The Forums Application
LDAP

17.7. VSP Guide

17.7.1. Introduction

Virtuoso Server Pages are the equivalent of a stored procedure in a Web page that is compiled when it is first read by the Virtuoso server. Virtuoso detects when the '.vsp' file is modified and recompiles the procedure. Since VSP is essentially Virtuoso PL in a Web page you can do anything that PL can, either directly or from interaction with the user. VSP gives you the advantage of not having to worry about making connections to the database. You also avoid the overhead of RPCs because the HTTP server is built into Virtuoso. When you write a VSP page the connection is automatic since you are already in Virtuoso.

VSP is server script and is therefore executed in the server as it is encountered on the page. For this reason client (JavaScript) and server script cannot directly interact but can supplement each other. You can call JavaScript inside a VSP loop, for example, to manipulate something that already exists on the page but you cannot pass variables by reference from VSP directly to JavaScript or vice versa.

Page flow control can be managed using FORMs. The state of the page is defined in form fields such as INPUT boxes and TEXTAREA boxes and then passed to the next form or page using POST.


17.7.2. Simple HTML FORM usage

We start with a small example that shows the source of a page including a FORM with data from the user being sent when a submit button is pressed. We then examine the elements and attributes of this simple form that are important to us at this stage.

17.7.2.1. Basic Forms

Simple Forms
<HTML>
  <HEAD>
    <TITLE>Simple FORM demo</TITLE>
  </HEAD>
  <BODY>
  <FORM METHOD="POST" ACTION="formdemo_receiver.vsp">
    <P>Test form, type some info and click Submit</P>
    <INPUT TYPE="TEXT" NAME="myInput" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>
  </BODY>
</HTML>

The METHOD attribute of a FORM TAG in a VSP page can be either GET or POST. The GET method allows the form submission to be contained completely in a URL; this can be advantageous because it permits bookmarking in browsers, but it also prevents form data from containing non ASCII characters such as accented letters and special symbols and restricts the amount of form data that can be handled. The GET method is l mited by the maximum length of the URL that the server and browser can process. To be safe, any form whose input might contain non-ASCII characters or more than 100 characters should use METHOD="POST".

With the POST method, the form input is submitted as an HTTP POST request with the form data sent in the body of the request. Most current browsers are unable to bookmark POST requests, but POST does not entail the character encoding and length restrictions imposed by GET.

The ACTION attribute of FORM specifies the URI of the form handler. This will usually be another web page that performs some action based on the data that is sent from the originating form. The URI could point to the same page as the data originated and for pages that perform a well-defined small set of functions it usually does. When a page needs to manage multiple states there needs to be some flow control that can determine how the page was reached; for example, to differentiate whether it arrived at as a result of someone clicking on the submit button or it is the first time the page has been visited.


17.7.2.2. Exchanging Values in Forms

Now we add some VSP to check the values of the parameters in the form. VSP markup is typically contained in <?vsp ... ?> blocks.

Forms and Values
<HTML>
  <HEAD>
    <TITLE>Simple FORM demo</TITLE>
  </HEAD>
  <BODY>
  <P>Last value sent:

  <?vsp
    http(get_keyword('myInput', params, 'no value'));
   ?>

</P>

  <FORM METHOD="POST" ACTION="formdemo.vsp">
    <P>Test form, type some info and click Submit</P>
    <INPUT TYPE="TEXT" NAME="myInput" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>
  </BODY>
</HTML>

This is the same example as above but now it uses the same page for the form handler and displays the parameters each time. Clicking the Submit button takes you to the same page and displays whatever you typed in the field last time.

The VSP block uses two nested functions. The http() function allows you to send data to the HTTP client, the browser. What we send to the browser is the result of the get_keyword() function, which has three parameters: search_for, source_array, and default_val. It searches for the keyword-value pair (keyword=value) where the keyword matches the search_for parameter (in this case 'myInput') in the array passed in the source_array parameter. It returns the value if one is found; otherwise returns the default_val parameter in the function, in this case 'no value'. The params argument is a special array that contains all page parameters from the previous FORM state.


17.7.2.3. Conditional Processing

Now we extend this further to add some conditional control so that if a value was entered we can respond directly to it. We will also use a variable this time, which must be declared first.

Conditional Processing Using IF
<HTML>
  <HEAD>
    <TITLE>Simple FORM demo</TITLE>
  </HEAD>
  <BODY>

  <?vsp
	declare _myInput varchar;

	_myInput := get_keyword('myInput', params, '');

    if (_myInput <> '')
	{	http('<P>Hello, ');
		http(_myInput);
		http('</P>');
	}
	else
	{	http('<P>Please enter your name</P>');
	}
   ?>

  <FORM METHOD="POST" ACTION="formdemo.vsp">
    <INPUT TYPE="TEXT" NAME="myInput" VALUE="" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>
  </BODY>
</HTML>

17.7.2.4. Further Page Control

We now extend this to control the whole content of the page. In this example we see that VSP and HTML can be interleaved.

Page Control
<HTML>
  <HEAD>
    <TITLE>Simple FORM demo</TITLE>
  </HEAD>
  <BODY>

  <?vsp
	declare _myInput varchar;
	declare Mode varchar;

	_myInput := get_keyword('myInput', params, '');
	Mode := get_keyword('submit', params, '');

    if (Mode = 'Submit')
	{
   ?>
    <P>Hello, <?vsp http(_myInput); ?>
	</P>

<FORM METHOD="POST" ACTION="demo4.vsp">
<INPUT TYPE="HIDDEN" NAME="myInput" VALUE="" />
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Again" />
</FORM>

  <?vsp
	}
	  else
	{
   ?>

  <P>Please enter you name</P>
  <FORM METHOD="POST" ACTION="demo4.vsp">
    <INPUT TYPE="TEXT" NAME="myInput" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>

  <?vsp
    }
  ?>
  </BODY>
</HTML>

We start by setting the mode based on whether the Submit button has been pressed. When the mode has changed a different version of the page is sent to the browser. In the new version, the Again button the appears, to return you to the previous state when pressed.


17.7.2.5. Communicating Parameters Between Pages

Now we will use two pages to do the same job as in the demo above.

Using more than one page

Page 1


<HTML>
  <HEAD>
    <TITLE>Multi Page Demo</TITLE>
  </HEAD>
  <BODY>
  <P>Please enter you name</P>
  <FORM METHOD="POST" ACTION="demo5_2.vsp">
    <INPUT TYPE="TEXT" NAME="myInput" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>
  </BODY>
</HTML>

Page 2


<HTML>
  <HEAD>
    <TITLE>Multi Page Demo</TITLE>
  </HEAD>
  <BODY>
  <P>The value you entered was:
  <?vsp
    http(get_keyword('submit', params, 'no data'));
  ?>
  </P>
  <FORM METHOD="POST" ACTION="demo5_1.vsp">
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Back" />
  </FORM>
  </BODY>
</HTML>


17.7.2.6. Using JavaScript to Control Forms

JavaScript is a programming language that can be used in the browser and is useful for client-side programming. It is useful to be able to do some work on the client machine before making another round trip to the server for more processing. JavaScript is also useful for making things more appealing to the Web page viewer.

JavaScript can be made to respond to events within the browser such as when the mouse is moved over a link, a graphic or a button or when the mouse is clicked on some part of the page. This can be achieved by using event handlers within the HTML tags and placing JavaScript code in their content. Common event handlers are onMouseOver, onMouseClick, onMouseOut, onChange, and the like.

A simple but useful example of this would be to simplify one of the previous examples by placing a handler on the text box so that you do not have to press the submit button to send the form to the server:

  <FORM METHOD="POST" ACTION="demo5_2.vsp" NAME="demo5_2">
    <INPUT TYPE="TEXT" NAME="myInput" onChange="document.demo5_2.submit()" />
    <INPUT TYPE="SUBMIT" NAME="submit" VALUE="Submit" />
  </FORM>


17.7.3. Interacting with the Database

This section describes manipulating data within Virtuoso from VSP. Unless the required tables already exist, new ones will need to be created. This example will involve a simple table of people and a series of pages for adding, editing, viewing, and deleting its entries.

17.7.3.1. Creating a Table

Tables should be created so that their entries can be uniquely identified. This is very important so that if we need to edit or delete one particular entry we can distinguish it from other entries. A primary key is how a database enforces unique rows, by refusing to allow duplicate data to be inserted. It is up to the user to choose a column in the table to act as a primary key. Sometimes one or more of the columns of data are naturally unique either singularly or in composite; other times it is necessary to add a column to contain unique codes for each row.

See Also:

Primary Keys

Here is the definition of the simple table that will be used:

CREATE TABLE DB.DBA.DEMO_PEOPLE (
  EMAIL VARCHAR(255) PRIMARY KEY,
  FORENAME VARCHAR(100),
  SURNAME VARCHAR(100)
);

The email address has been selected as a primary key.


17.7.3.2. Basic Form Input Page

After the table has been created - for example via Virtuoso's iSQL utility - it will need some data. For this we create a "New Person" page. This page uses form inputs and some VSP code to determine whether an insert button was pressed. If the insert button is pressed then the page takes submitted values from the POST and uses them to construct an SQL statement that inserts a new row into the table. This is demonstrated below:

<HTML>
  <HEAD>
    <TITLE>New Person Page</TITLE>
  </HEAD>
  <BODY>
  <?vsp

    declare _email, _forename, _surname varchar;

    _email := get_keyword('email', params, '');
    _forename := get_keyword('forename', params, '');
    _surname := get_keyword('surname', params, '');

    -- insert new person if we came from the insert button
    if ('' <> get_keyword('ins_button', params, ''))
    {
      INSERT INTO DB.DBA.DEMO_PEOPLE(EMAIL, FORENAME, SURNAME)
        VALUES(_email, _forename, _surname);
    }
  ?>
  <P>Please enter the details of new person:</P>

  <FORM METHOD="POST" ACTION="demo_people_add.vsp">
  <TABLE>
    <TR><TH>Email:</TH><TD><INPUT TYPE="TEXT" NAME="email" /></TD></TR>
    <TR><TH>Forename:</TH><TD><INPUT TYPE="TEXT" NAME="forename" /></TD></TR>
    <TR><TH>Surname:</TH><TD><INPUT TYPE="TEXT" NAME="surname" /></TD></TR>
  </TABLE>

  <INPUT TYPE="SUBMIT" NAME="ins_button" VALUE="Insert" />
  </FORM>

  </BODY>
</HTML>

The underscores were added to this example to keep the param variables and page variables visibly distinguishable.


17.7.3.3. Displaying Table Data in a VSP Page

Now that some data exists in the table we need a way to display it. The FOR ... DO construct is used to construct the insides of an HTML table:

<HTML>
  <HEAD>
    <TITLE>The People Page</TITLE>
  </HEAD>
  <BODY>
  <P>The Peoples' Details</P>

  <TABLE>
    <TR><TH>Email</TH><TH>Forename</TH><TH>Surname</TH></TR>
  <?vsp
    FOR (SELECT EMAIL, FORENAME, SURNAME FROM DB.DBA.DEMO_PEOPLE) DO
    {
  ?>
    <TR><TD><?=EMAIL?></TD><TD><?=FORENAME?></TD><TD><?=SURNAME?></TD></TR>
  <?vsp
    }
  ?>
  </TABLE>
  </BODY>
</HTML>

17.7.3.4. Simple Form Delete Page

The page above can easily be extended to allow deletion. For each row an 'action' link is added. The action Remove link hardwires a form GET on the URL. This is then intercepted by the IF condition looking for the remove parameter.

<HTML>
  <HEAD>
    <TITLE>The People Page With Deletion</TITLE>
  </HEAD>
  <BODY>
  <?vsp
    declare deleteme varchar;

    deleteme := get_keyword('remove', params, '');
    if ('' <> deleteme)
      DELETE FROM DB.DBA.DEMO_PEOPLE WHERE EMAIL = deleteme;
  ?>

  <FORM METHOD="POST" ACTION="demo_people_view2.vsp">
  <P>The Peoples' Details</P>

  <TABLE>
    <TR><TH>Email</TH><TH>Forename</TH><TH>Surname</TH>
      <TH>Action</TH></TR>
  <?vsp
    FOR (SELECT EMAIL, FORENAME, SURNAME FROM DB.DBA.DEMO_PEOPLE) DO
    {
  ?>
    <TR><TD><?=EMAIL?></TD><TD><?=FORENAME?></TD><TD><?=SURNAME?></TD>
      <TD><A HREF="?remove=<?=EMAIL?>">Remove</A></TD></TR>
  <?vsp
    }
  ?>
  </TABLE>
  </FORM>
  </BODY>
</HTML>

17.7.3.5. Simple Form Edit Page

The last step is to have a way to edit rows of the table. To do this, we combine everything that we have so far and use the SQL UPDATE statement to update the row. The EMAIL column is not made updateable since this is the primary key.

<HTML>
  <HEAD>
    <TITLE>The People Page With Deletion</TITLE>
  </HEAD>
  <BODY>
  <FORM METHOD="POST" ACTION="demo_people_view3.vsp">
  <?vsp
    declare deleteme, editme, edt_email, edt_forename, edt_surname,
            save_email, save_forename, save_surname varchar;

    deleteme := get_keyword('remove', params, '');
    if ('' <> deleteme)
      DELETE FROM DB.DBA.DEMO_PEOPLE WHERE EMAIL = deleteme;

    if ('' <> get_keyword('save_button', params, ''))
    {
      save_email := get_keyword('email', params, '');
      save_forename := get_keyword('forename', params, '');
      save_surname := get_keyword('surname', params, '');

      update DB.DBA.DEMO_PEOPLE
        SET FORENAME = save_forename, SURNAME=save_surname
        WHERE EMAIL = save_email ;
    }

    editme := get_keyword('edit', params, '');
    if ('' <> editme)
    {
      SELECT EMAIL, FORENAME, SURNAME
        INTO edt_email, edt_forename, edt_surname
        FROM DB.DBA.DEMO_PEOPLE WHERE EMAIL = editme;
  ?>
  <TABLE>
    <TR><TH>Email:</TH><TD><INPUT DISABLED TYPE="TEXT" NAME="email" VALUE="<?=edt_email?>" /></TD></TR>
    <TR><TH>Forename:</TH><TD><INPUT TYPE="TEXT" NAME="forename" VALUE="<?=edt_forename?>" /></TD></TR>
    <TR><TH>Surname:</TH><TD><INPUT TYPE="TEXT" NAME="surname" VALUE="<?=edt_surname?>" /></TD></TR>
  </TABLE>
  <INPUT TYPE="SUBMIT" NAME="save_button" VALUE="Save" />
  <?vsp
    }
  ?>

  <P>The Peoples' Details</P>

  <TABLE>
    <TR><TH>Email</TH><TH>Forename</TH><TH>Surname</TH>
      <TH>Action</TH></TR>
  <?vsp
    FOR (SELECT EMAIL, FORENAME, SURNAME FROM DB.DBA.DEMO_PEOPLE) DO
    {
  ?>
    <TR><TD><?=EMAIL?></TD><TD><?=FORENAME?></TD><TD><?=SURNAME?></TD>
      <TD><A HREF="?remove=<?=EMAIL?>">Remove</A> <A HREF="?edit=<?=EMAIL?>">Edit</A></TD></TR>
  <?vsp
    }
  ?>
  </TABLE>
  </FORM>
  </BODY>
</HTML>


17.7.4. The Forums Application

The "Forums" Application is a World Wide Web Application for posting, reading and searching of messages developed under the Virtuoso VDBMS with a wide usage of Virtuoso Server Pages (VSP) and server-side XSL-T transformation.

Messages in the forums are classified to forums and sub-forums by interest. Posting is only allowed for registered users. Registration is performed via a registration form. Every registered user can create new a theme, post new messages to an existing theme or reply to an existing message. Unregistered users can only search, browse, and read existing themes and messages.

17.7.4.1. Principles

The application is based on VSPs, XML and XSLT transformations. The VSPs are used to produce XML documents that are transformed to HTML using server side XSLT. The design and appearance of the application depends solely on XSLT style sheets. This allows us to divide the development into two distinct parts: layout and design, and functionality of the application.

Session management is based on URL manipulation and persistent HTTP session variables. The messages are stored in Database as XML documents with a free-text index applied over them.


17.7.4.2. Navigation

The application consists of four main pages:

  1. home.vsp - the main page introduces the forums with the following information:

    • Forums: name of each forum with link to the relevant sub-forums.
    • Total: total number of messages for this forum.
    • New: new messages for this forum within the last day.
    • Last: number of the last message inserted in the forum.
    • Total users: count of registered users.
    • Options: login if the user is already registered in the forums.
    • Registration: add a new user.
    • Search: search in the messages.
  2. subforums.vsp - sub-forums of the current forum with the following information:

    • Subforum: name of each sub-forum with links to relevant themes.
    • Total: total number of messages for this forum.
    • New: new messages for this forum within the last day.
    • Last: number of the last message inserted in the forum.
    • Options: login if the user is already registered in the forums.
    • Registration: add a new user
    • Search: search in the messages.
    • Forums path: links to the home page and to the forum to which the current sub-forums belong.
  3. forum.vsp - themes of the current sub-forum with the following information:

    • Theme: name of each theme with links to its messages.
    • Total: total number of messages for this theme.
    • New: new messages for this theme within the last day.
    • Last: number of the last message inserted in the theme.
    • Options: login if the user is already registered in the forums.
    • Registration: add a new user.
    • Search: search in the messages.
    • Forums path: links to the home page, to the forum and to the sub-forum to which the current themes belong.
  4. thread.vsp - messages of the current theme with the following information:

    • Message: name of each message with a link to its properties. When the link is activated the same page is presented, but with the tree of messages for which the current message is the parent.
    • Author: the name of the author of the current message.
    • Date: posting date of the message.
    • Options: login if the user is already registered in the forums.
    • Registration: add a new user.
    • Search: search in the messages.
    • Forums path: links to the home page, to the forum and to the sub-forum to which the current message belongs. Also for the current message, the parent message's name is presented. As users move lower in the tree, they can go back using this path.

17.7.4.3. Remarks

The basic principles of the application's implementation are:

If users are not logged in they can access all pages of the site, but if they want to insert a new theme or create a new message, they have to log in. When users attempt to create or insert, they will be prompted with the login page. When they log in, the forums application will take them directly to the form for inserting messages or themes. If users are not logged in, the name 'anonymous' is displayed, instead of the e-mail address that would be displayed if they were logged in.


17.7.4.4. The Search Page

Users can search in three ways:

Search results contain information about how many hits were found, and for each hit the following:

The search page provides the interface for searching contents of forums including messages and titles.

<?vsp
  declare id, acount, aresults integer;
  declare aquery, awhat, askiped, search_res, sid, uid, url, usr varchar;

  -- > at this point we instruct server to do server-side XSLT transformation
	-- >    over resultant document
  -- > The transformation will be done before sending the document to the user-agent
  -- >    and after page execution is done.
	-- > To provide flexible file location we use a registry setting for XSLT
	-- >    style sheets
  http_xslt(sprintf ('file:%s/search.xsl', registry_get ('app_forums_xslt_location')));

  -- > because the application does URL poisoning for session management
  -- > we must retrieve the request parameters:

  -- > the session ID
  sid      := get_keyword('sid', params, '0');
  -- > the query text
  aquery   := get_keyword('q',params,'');
  -- > the query locator (for what we searching)
  awhat    := get_keyword('wh',params,'t');
  -- > how many records to skip
  askiped  := atoi (get_keyword('sk',params,'0'));
  -- > how many results to return
  aresults := atoi (get_keyword('rs',params,'10'));
  -- > hits count
  acount   := atoi (get_keyword('c',params,'0'));

  url := 'thread.vsp';

  -- > also we get the user ID from the session variables
  uid := connection_get ('pid');
  usr := connection_get ('usr');

  -- > now we are ready and call the stored procedure that returns the result from search
  search_res := FORI_SEARCH_RES (aquery, awhat, askiped, aresults, acount);
?>
<!-- now we produce the result as well-formed XML document -->
<?xml version="1.0"?>
<page>
<sid><?=sid?></sid>
<usr><?=usr?></usr>
<url><?=url?></url>
<nav_2><?vsp http(FORI_SEARCH_FORM (sid, aquery, awhat, askiped, aresults, acount)); ?></nav_2>
<css_1/>
<squery><?=aquery?></squery>
<swhat><?=awhat?></swhat>
<sskiped><?=askiped?></sskiped>
<sresults><?=aresults?></sresults>
<scount><?=acount?></scount>
<?vsp http (search_res); ?>
<?vsp http (FORI_SEARCH_NAVIGATION (
  sprintf('search.vsp?q=%s&wh=%s&rs=%d&c=%d&sid=%s&', aquery, awhat, aresults, acount, sid),
	  acount, askiped, aresults)); ?>
</page>

17.7.4.5. Search Page Analysis

First we declare the variables used inside the page. In VSP, variables can be defined at any time, but it is generally good practice is to declare them near the top.

We call http_xslt() with a file URL parameter. This instructs the Virtuoso server to do XSLT transformation on the server side before sending output to the client, and after execution of the page. Hence we will produce an XML document.

After this we need to get the input parameters session_id, query text, how many records to skip, and how many records to display. We do this by calling get_keyword() and passing it the 'params' array. Every VSP page has params, path, and lines as input parameters. For each call we supply a default value in case the variable has not been used. For some of the parameters we need an integer, but varchars are always returned, so we use atoi() on the result to convert it to an integer.

Next we retrieve the persistent variables user id and user name. We do this by calling connection_get() with the session variable name.

After this preparation, we are ready to perform the searching by calling the PL stored procedure FORI_SEARCH_RES(). This procedure returns the XML entities that contain the results from the search.

Once we have results, we want to produce the XML document that will be used in the XSLT transformation. We do this part of the work using the shortcuts to the http_value() function: '<?= ?>' pairs, and also in some places '<?vsp ?>' to call the FORI_SEARCH_FORM() and FORI_SEARCH_NAVIGATION() procedures and output their results.

The main benefits to this approach are:

If we comment out the line that instructs Virtuoso to perform the XSLT transformation (http_xslt()) we will get the following document:

<?xml version="1.0"?>
<page>
<sid>0</sid>
<usr>anonymous</usr>
<url>thread.vsp</url>
<nav_2><search_form>
<hidden>
<hidden_input type="hidden" name="sid" value="0" />
<hidden_input type="hidden" name="sk" value="0" />
<hidden_input type="hidden" name="rs" value="10" />
<hidden_input type="hidden" name="c" value="0" />
</hidden>
<select name="wh">
<option value="t" selected="1">theme title</option>
<option value="mt">message title</option>
<option value="mb">message body</option>
</select>
</search_form>
</nav_2>
<css_1/>
<squery></squery>
<swhat>t</swhat>
<sskiped>0</sskiped>
<sresults>10</sresults>
<scount>0</scount>
<search_result>
<no_hits/>
</search_result>
<navigation pages="0">
</navigation>
</page>

If we re-enable the XSLT transformation the user agent will receive the following HTML content:

<html><head>
<style type="text/css">
a:hover{color:#a2a2a2}
.id{font-size:12px;font-family:arial,sans-serif;font-weight:bold;color:#004C87}
.ie{font-size:12px;font-family:verdana,sans-serif;color:#FFFFFF}
.ir{font-size:14px;font-weight:bold;font-family:verdana,sans-serif;color:#FFFFFF}
.if{font-size:12px;text-decoration:none;font-family:verdana,sans-serif;
   font-weight:bold;color:#E1F2FE}
.iname{font-size:12px;font-weight:bold;font-family:verdana,sans-serif;color:#FFFFFF}
.ipath{font-size:12px;text-decoration:none;font-weight:bold;
   font-family:verdana,sans-serif;color:#004C87}
.inew {font-size:12px;text-decoration:none;font-weight:bold;
   font-family:verdana,sans-serif;color:#FFC600}
.text {font-size:12px;text-decoration:none;font-family:Arial,sans-serif;color:#004C87}
</style>
</head>
  <body>
    <TABLE WIDTH="100%" BGCOLOR="#004C87" CELLPADDING="0" CELLSPACING="0" BORDER="0">
     <TR>
      <form action="search.vsp" method="post">
        <TD WIDTH="20%" VALIGN="top">
          <IMG SRC="i/logo_n.gif" HEIGHT="49" WIDTH="197" BORDER="0"></TD>
	<TD WIDTH="40%" ALIGN="center">
	  <input type="text" name="q" size="36" value=""></TD>
	<TD WIDTH="25%" ALIGN="center">
	   <select name="wh">
	      <option value="t" selected>theme title</option>
	      <option value="mt">message title</option>
	      <option value="mb">message body</option>
	   </select> <input type="hidden" name="sid" value="0">
	   <input type="hidden" name="sk" value="0">
	   <input type="hidden" name="rs" value="10">
	   <input type="hidden" name="c" value="0">
	</TD>
	<TD WIDTH="15%">
	<input type="image" name="search" src="i/search.gif" border="0"></TD>
	</form>
      </TR>
   </TABLE>
    <TABLE WIDTH="100%" BGCOLOR="#02A5E4" CELLPADDING="0" CELLSPACING="0" BORDER="0">
      <TR>
	<TD>
	    <IMG SRC="i/str.gif" HEIGHT="12" WIDTH="35">
	    <a class="id" href="home.vsp?sid=0">Home</a>
       </TD>
       <TD HEIGHT="22" class="iname" ALIGN="right">anonymous </TD>
      </TR>
      </TABLE>
      <TABLE BGCOLOR="#E1F2FE" ALIGN="center" WIDTH="100%" CELLPADDING="0" CELLSPACING="0" BORDER="0">
       <TR>
         <TD COLSPAN="3">
 	    <IMG SRC="i/c.gif" HEIGHT="12" WIDTH="1">
         </TD>
       </TR>
       <TR>
        <TR BGCOLOR="#0073CC">
         <TD WIDTH="60%" HEIGHT="24" class="ie"> message title</TD>
         <TD WIDTH="20%" class="ie">time</TD>
         <TD WIDTH="20%" class="ie">author</TD>
       </TR>
      <TR>
        <TD COLSPAN="3">
          <IMG SRC="i/c.gif" HEIGHT="2" WIDTH="1">
        </TD>
      </TR>
      <TR>
        <TD align="left" class="id" COLSPAN="3">No hits found</TD>
      </TR>
      <TR>
       <TD HEIGHT="18" colspan="3" BGCOLOR="#0073CC" class="id">
       </TD>
      </TR>
     </TR>
     <TR>
       <TD COLSPAN="3">
         <IMG SRC="i/c.gif" HEIGHT="2" WIDTH="1">
       </TD>
     </TR>
     <TR>
      <TD COLSPAN="3" BGCOLOR="#0073CC">
        <IMG SRC="i/c.gif" HEIGHT="1" WIDTH="1">
      </TD>
     </TR>
    </TABLE>
  </body>
</html>

The page sources are available in the default distribution under the samples directory.

See Also:

For more information about the functions used see: http_xslt(), http(), http_value().

For more information about VSP in general go the VSP Section.