I've already mentioned some of the advantages of AOLserver. While
the integration with TCL, the pleasures of a good database
interface, and it's threading have all been mentioned AOLserver has
even more wonderful qualities.
Templating: Separation of data, business logic, and
presentation is very important to maintaining the sanity of any
developer. While the database helps to abstract away data-storage
the availability of a good templating facility helps to separate
business logic and presentation. AOLserver's built-in ADP system is
a start, but is definitely far from perfect. It allows individuals
to insert TCL code inside of what is otherwise a normal HTML
document. This is ok in situations like this:
<head>
<title><%=$title%></title>
</head>
but in situations like this:
<table>
<% foreach item $items {
puts "<tr>\n"
puts " <td align=\"right\">[lindex $item 0]</td><td>[lindex $item 1]</td><td>[lindex $item 2]</td>\n"
puts "</tr>\n"
}
%>
</table>
you may find that your average HTML monkey runs for the hills.
One URL to One File: One of my favorite things about OpenACS
is the idea that one URL maps to one file (pretty much). This is
not the case with servlets, or Zope. In servlets any number of
different URL's will map to the same servlet, and in Zope each URL
represents some object in their Object Database, or the method of
some Python Object. When a user requests:
GET /bboard/forum-view?oid=1245
This will typically mean run a script at
"$ROOT/www/bboard/forum-view". This makes things easy to debug and
usually prevents you from having truly enormous files.
Filters: Now that I've just discussed why I like "One URL to
One File", I'll totally contradict myself by discussing filters.
Filters allow an action to be taken before a request occurs. If you:
ns_register_filter do_something /*.jpg
do_something will be run whenever you request a .jpg file. This
allows you to do authentication, session tracking, etc. Filters
return a message like FILTER_OK, FILTER_BREAK, FILTER_RETURN which
cause effects from allowing other filters to run, to ending the
request, to carrying on as if nothing has happened. Filters are
sometimes dangerous as they violate the Unix principle of least
surprise. They can act invisibly and introduce new unforseen
problems, but they are also a useful tool to quickly add
functionality to an entire site, or to a particular module.
Connection API: One of the things we like our webservers to
do is protect us from the particulars of HTTP. AOLserver provides
the "ns_conn" api which allows developers to get information about
the HTTP request without having to parse it out themselves.
There are other nice AOLserver services, including a plugin
architecture that allows you to add lots of new modules for handling
things like XML, SSL and XSLT. It is easily extensible in C, and
since it's configuration files are written in TCL you can script
most of your configuration options.