Re: A summary of key points on dynamically generated web pages

One problem with dynamically generated pages is that one has 
to configure the server to send the appropriate last-modified 
response header to allow caching.

In addition, the server would like documents to be cached only 
if it can assure that the cached document that is served to 
the user is the appropiate variant.

The simplest way to solve this problem is to have 
prewritten "static" versions on the server, with different URLs, 
and the server may use redirects (using a response with 302 
status code) based on content negotiation. (Content negotiation 
includes user-agent request header). 

Having each variant with a different URL makes the documents that the users 
receive non-negotiated documents that can be cached, and using static files 
makes the last-modified header a trivial matter: usually the server will 
use the operating system's information about the file in question.

However even with this solution you get less caching than with serving 
one document with one URL.

So I would recommend to 
1. attempt to reduce the number of variants to a minimum. (using diffeent 
 style sheets per different media and following WAI guidelines)
2. If more than one variant is served, have them with different URLs 
 and make sure the appropriate last-modified header is sent.

What is this "mimimum" in article 1 above if a function of what 
clients can actually do. (support to which style sheet languages, what level, 
bugs etc.)

Clearly, all this matters only if the document is "otherwise static".
In case of serving pages based on user input that can not 
be repeated by other users, caching is irrelevant anyway.

At 11:46 AM 11/22/99 -0800, Scott Luebking wrote:
>Hi,
>
>I thought it might be helpful to boil down what I sent out last week
>on dynamically generated web pages.
>
>1.  A server generates a web page by basically gathering information from
>    one or more data sources like databases, XML documents, real time
>    data suppliers, dynamic data generators, etc; analyzing the
>    information as appropriate; deciding the format to present the
>    information and then creating the web page in the format selected.
>
>2.  Since the document does not exist before the server generates it,
>    the server can easily generate the document in multiple forms.  This
>    flexibility lets the document be generated in a form which is designed
>    for visual users and also a form which is designed for blind users.
>
>3.  The ability to generate a document in multiple forms avoids the
>    problem of compromising a desired visual form for the accessibility
>    of the page for blind users and the problem of compromising
>    accessibility for blind users to achieve a certain desired
>    visual presentation.
>
>4.  Allowing the programmer handle the form of a generated web page
>    at the software level will be easier and more efficient.  The software
>    has to generate the document any way.  Supporting multiple
>    forms will probably not be much harder.  Also, it avoids the problem
>    that the programmer can run into with version skews, etc,
>    for tools like CSS, etc.
>
>
>Is there anything that I'm missing in this technical analysis?
>
>Scott
> 
===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145

Received on Monday, 22 November 1999 22:03:14 UTC