ie. supplying data to web pages dependent on user
requests
methods:
pre-programmed HTML generation:
automatic programmed creation of static
HTMLs as data in a table changes
requires only that the HTML file is
recreated each time underlying data is
changed:
manual programming
HTML generator
Server side programming only (ie. zero-client configuration):
Server Side Includes (SSI):
An SSI is a command or directive placed in an HTML file
through the use of a comment line. With a simple SSI command
you can update an entire site design, dynamically add the
current time and date or the date a file was last modified,
execute shell and CGI scripts and more! A definite boon to web
developers who are short on funds and time and over worked
with a gazillion pages to manage.
web pages using these have the extension shtml
A file that contains includes must be parsed by the
server. This puts an extra load on the server but unless
your site receives [millions] of visitors a day it's
unlikely you'll notice a slow-down in load time. Still, if
you're not using includes to add the headers and footers
to your entire site there's really no need to parse every
single page. If your plan is to just add a few includes to
special pages, give them a file extension of .shtml and
the server will parse only those pages. On the other hand,
if you have an existing site of multiple pages, plan to
use includes to add headers and footers and don't look
forward to renaming all of your files to .shtml you can
add the line
AddType text/x-server-parsed-html
.html
to your .htaccess file instead. All of your pages will be
parsed, but they'll need to be anyway to grab those
headers/footers.
They were first introduced in the NCSA server;
If you do not wish to allow scripts or shell commands to be
run add IncludesNOEXEC to the options line. This
will allow SSIs but not CGI or shell commands.
a SSI looks like: <!--#exec cgi="filename.cgi"-->
//ie. the commands are embedded within comments and are
preceded by #
Another command available in SSI's is #include, as opposed
to #exec. This command does not execute a program that you
must write - instead, it just inserts a file into your web
page
BUT:
Not all sites have SSI's enabled at all. You'll have to
mail your sysadmin to see if you can use them.
Some sites do not allow scripts do be executed in user's
home directories. This means that you cannot do any of
this simply. Ask your sysadmin, once again.
Some sites have #exec disabled, but not other SSI's.
Some sites do not have Perl installed on their system in
which case can't use Perl scripts
Common Gateway Interface (CGI) scripts:
a CGI web server application is a console application
loaded by the Web Server for each request & unloaded
directly after completing the request & thus does not
scale well
it is thus slower than ISAPI which is NOT unloaded but
is more robust than ISAPI as it is much less likely to
bring the web server down with a rogue DLL.
winCGI is a Window's specific implementation of CGI
which instead of a standard input & standard output,
uses an INI file to send data back & forth.
Delphi implementation of CGI:
File:New:WebServerApplication then select CGI
but consider making an ISAPI application (see below)
then converting it back to CGI afterwards by:
replacing ISAPIApp with CGIApp in project uses
clause
removing the project Exports clause which
contains 3 ISAPI-related exports.
Perl provides DBI module which allows your CGI
script to talk to database drivers (eg. Sybase,
Oracle, ODBC)
ISAPI:
uses an ISAPI dll to parse your dynamic
web pages
eg.
www.mysite.com/ISAPI/MyIsapi.dll/Signin
NB. if you can edit your web
server, you may be able to
configure it so that a certain
file extension (eg. 'dwm') is run
by the executable myISAPI.dll, in
which case you would be able to
avoid the above clumsy explicit
dll call & just use your HTML
filename with the new extension.
Delphi implentation of ISAPI (CGI is similar!):
create ISAPI dlls via
File:New:WebServerApplication -
ISAPI/NSAPI Dynamic Link Library
drop the following components on the form:
TWebModule - allows definition of
TWebActionItems & set event handlers for each
TWebResponse - allows setting content for a web
response: text/HTML content or image via
contentStream
can use in WebModuleWebActionItemAction
event:
Response.content := PageProducer.content;
TWebRequest - holds the input query eg. POST/GET
methods
a HTML generator object such as one of these:
TPageProducer - creates HTML allowing use of
special tags which can be replaced by text in
the OnHTMLTag event with its variable
ReplaceText
TDataSetPageProducer - as for TPageProducer
but has a dataset property and attempts to
find a field name in the dataset which matches
the tag and then ReplaceText is assigned the
dataset field value automatically but require
additional coding if either:
memo fields
field name contains spaces
TDatasetTableProducer - as for
TDataSetPageProducer but creates a grid of
records rather than just one record
TQueryTableProducer - as for
TDatasetTableproducer but allows parameterised
queries
To browse a dataset, one needs to keep note of
which record is the current one as http is
stateless ..ie. one has to save
state information
ASPs are server-generated pages which can call other
programs to do things like access databases, serve
different pages to different browsers - basically,
anything we used to do with CGI. ASP is almost as
efficient as writing code directly to the server's
application program interface, and it's a lot more
efficient than CGI because it runs as a service and can
take advantage of multithreaded architectures.
this allows one to easily create a web
server that connects to an application
server via DCOM to generate interactive
web client HTML pages with data grids,
data navigation, apply updates buttons.
Delphi utilises DCOM, MIDAS, XML, java
script and HTML to achieve this and
generates an ISAPI dll
Client side processing only:
Active Forms:
Wintel-only web pages
Delphi can create Active Form via
File:New:ActiveX:ActiveForm
the web is "stateless" ie. your pages
do not automatically detect who requested data so
that if you do dynamically alter data on web page
then either all users will get that data or it
will apply only to the page immediately preceding
it (eg. processing a form page)
to get around this limitation, a mechanism must
be implemented that stores data about the
identity of the user & remember user-selected
data as required.
there are 3 mechanisms to implement state:
forms:
to maintain state with forms, you
would have to place every link on
your site in an HTML form, and
store the state ID in a hidden
field, then as the user navigates
the site, the ID would be passed
in the Request.ContentFields
variable in each request.
this is NOT a viable approach
because of the overhead &
pain involved in implementing
every link as a form UNLESS you implement this
via Delphi's TDatasetPageProducer using tags for
record number or similar (see Delphi 4 Unleashed
page 580)
cookies:
you generate a unique session or
user ID, store it in a cookie
that is placed on the visitor's
computer when they first enter
the site.
on subsequent pages, the cookie
is pulled from the page request
& used to access the
visitor's state information
advantages:
you can set up the cookie
just once eg. in
WebModuleBeforeDispatch
event
you can store a permanent
ID for a visitor so that
he will be recognised
next time & then
personalised data can be
provided eg. preference
settings
disadvantages:
some users turn cookies
off
if you use cookies to
maintain state, they
should expire soon after
their last use
if you use cookies to
identify a user, it
should be permanent, BUT
if more than one user
uses the visitor's
computer, this will need
to be taken into account!
fat URLs:
embed a session ID in the URL
visitors use to navigate your
site
generate a unique identifier when
the 1st page is requested
on all subsequent pages, any
internal links will have an
argument in their URL that passes
along the ID
an internal link may look like:
<a href =
'/demo/page2.htm?SID=<#SessID>'>
in all page requests after the
first, you would pull down the
session ID from the
Request.QueryFields
disadvantages:
have to include sessionID
in every internal link
have to write code in
every action item or
PageProducer to
substitute in the
sessionID
every page now needs
dynamic processing to
achieve this
HOWEVER, you can use DI
July 2000 TMDWeb
components to automate
this somewhat.
non-Delphi programs that act as
"Application Servers":
these usually manage session state,
persistence, load balancing, database
locking & data replication
examples:
Allaire ColdFusion Server:
includes JIT compiling,
caching, native DBMS
support to Sybase 11,
Oracle, Informix, DB2, MS
Access/SQL OLE, &
ODBC/JDBC
user ClusterCATS
technology to provide
load balancing & fail
over in server clusters
runs on Windows or Linux
web pages use ColdFusion
Markup Language (CFML)
Apple WebObjects:
object oriented (uses
java server objects &
Objective C language) web
page development system
with business logic
separated from web page
template