Download Table of Contents I 3

Table of Contents
INTRODUCTION
3
What IS ClioWeb?
3
Who is responsible for ClioWeb?
3
Who should read this manual
3
What’s new in ClioWeb 3.0?
3
How ClioWeb works
4
The Clio system information chain
5
INSTALLATION
5
INSTALLATION
6
Install ColdFusion on your Web server
6
Set up ClioWeb’s datasource
6
Windows servers
Linux servers
Put ClioWeb’s folders and pages in place
6
7
7
THE LOGIN PROCESS
9
The First Option
The Second Option
9
9
SETUP AND CONFIGURATION
11
Some ColdFusion Basics
11
Some ClioWeb conventions
11
Configuring ClioWeb
12
ClioWeb’s structure
settings.cfm
12
14
‘INFRASTRUCTURE’ PAGES
15
Application.cfm
settings.cfm
inputfilter.cfm
mailer.cfm
authcheck.cfm
deleter.cfm
‘VISIBLE’ PAGES
General page construction issues
15
15
15
15
15
15
16
16
Index.cfm
16
cwlogin.cfm
16
Menu.cfm
17
Results.cfm
18
ClioWeb 3.0 Manual, version 1
1
2
ViewPDF.cfm
20
Reqform.cfm
21
Mailform.cfm
21
Cwlogout.cfm
22
cwerror.cfm
23
ClioWeb 3.0 Manual, version 1
Introduction
What IS ClioWeb?
ClioWeb is a ColdFusion Web application designed to provide an out-of-the-box patron Web
access solution for an ILL department that uses the Clio ILL system. ClioWeb is a complete and
flexible ILL website that you can use in its entirety, or you can utilize just pieces of it within your
existing website.
ClioWeb is designed to be easily customizable so that you can seamlessly blend it into your
institution’s existing Web presence. I am happy to help with customizing the appearance and
content of your ClioWeb site in addition to customizing its construction and functionality to suit
the needs of your institution.
ClioWeb also includes a Clio module to facilitate the delivery of documents that have been
delivered electronically via the Ariel system to your patrons via your ClioWeb site. This module
is called ClioEDelivery and will be addressed separately.
Who is responsible for ClioWeb?
This manual makes frequent use of the words ‘I’ and ‘me’, as in “call me if you have a problem”.
Who is ‘I’?
I am Richard Perkins, designer of ClioWeb and author of this manual. I am responsible for all
ClioWeb-related things here at Clio Software (among other things) and am here to help you get
your ClioWeb site running and looking however you want it. This is my contact information:
Richard Perkins
[email protected]
510-326-5987
PLEASE call or email if you have any problems or questions about ClioWeb. You have paid
quite a bit of money for ClioWeb precisely because it is a semi-custom product that is complicated
to set up and configure. However much assistance from me it takes to get your ClioWeb site just
how you like it is included in ClioWeb’s purchase price, so PLEASE call me and put me to work
for you! There’s nothing worse than hearing from a disgruntled customer who’s had ClioWeb for
six months and never got it to work when I could have solved their problem in two seconds, had
they only called me. I may not always be able to answer my phone (that’s my cell phone number
up there), but I swear I will call you back if you leave me a message.
Who should read this manual
This manual is intended for IT systems professionals who deal with web servers, web
programming and network administration. This manual describes how ClioWeb works and the
tasks that need to be performed to get it going and maintain it. ClioWeb is designed in such a way
that it can be maintained by just about anyone once it is set up and working, but the process of
getting ClioWeb set up and working requires experience in web programming, web server
management and network administration.
What’s new in ClioWeb 3.0?
ClioWeb 3.0 includes many profound changes from previous versions. If you are a current
ClioWeb user, you are in almost the same boat as people who are starting with ClioWeb 3.0 as
their first ClioWeb version.
ClioWeb 3.0 Manual, version 1
3
Now based on ‘Full’ ColdFusion
Almost all of ClioWeb 3.0’s changes and new features stem from the fact that it is intended to be
used with full-featured, purchased versions of ColdFusion. Prior versions of ClioWeb were based
on the free ‘Express’ version of ColdFusion that is now rather out of date and not readily
available. With the performance improvements and, most importantly, the price drop introduced
with the MX generation of ColdFusion, we felt that it was time to base ClioWeb on fully-featured,
purchased versions of ColdFusion. This change VASTLY simplifies ClioWeb’s setup and
configuration tasks and greatly improves the performance and security of your Web server.
ClioWeb 3.0 is intended to be used with ColdFusion MX or later, but can also be used with
ColdFusion 5.0.
Some of the changes and additions to ClioWeb that derive from this switch include:
•
Email now handled within ClioWeb/ColdFusion where it used to be handled by a Perl
application named Soupermail.
•
Free advanced reports and charts will be available on the ClioWeb users’ site for you to
download and add to your site.
•
The login/authentication process is greatly simplified and handled much more reliably by
using ColdFusion’s Session variable tracking capability.
•
The overall complexity of ClioWeb is reduced.
How ClioWeb works
In the most general terms, ClioWeb is a collection of special Web pages that will reside on your
Web server. These pages will make use of ColdFusion software on your server to do fancy things
like extract data from a copy of your Clio database and include this data in Web pages displayed to
your library’s patrons. ClioWeb’s pages also include the facility for patrons to email new ILL
requests, item renewal requests, and general-purpose emails to your ILL staff.
Where are my books?
1
Your Web
Server
2
5
ColdFusion
Server
Software
4
Copy of
Clio DB
3
Replication
process
Real
Clio DB
Requested
ColdFusion
page
template
Small text
files
4
ClioWeb 3.0 Manual, version 1
What is going on in this diagram?
1. A patron requests to see one of your ClioWeb pages.
2.
Your Web server realizes that the page in question is a ColdFusion template and turns the
handling of this request over to the ColdFusion Server software that is running on the
server for processing.
3.
ColdFusion interprets the instructions contained in the page template and gathers data
from a copy of your Clio database and some small text files.
4.
ColdFusion assembles all the relevant information and generates a unique HTML
webpage in a few milliseconds.
5.
The custom webpage is sent to the patron that requested it with no trace of how it was
constructed, other than the .cfm file name, if visible.
The Clio system information chain
Staff
Use
Electronically
delivered documents in
PDF format
ClioEDelivery
Patron
Use
Request status
information
ClioWeb
Clio
Other Libraries via
the Ariel system
Other Libraries,
OCLC, and more.
New ILL requests
ClioRequest
ClioWeb 3.0 Manual, version 1
5
Installation
Installing ClioWeb is fairly quick and easy; it’s the setup and configuration tasks that follow that
take some time and effort.
Install ColdFusion on your Web server
Most ClioWeb users are new to ColdFusion. ColdFusion MX Professional is included in the
purchase price of ClioWeb and is usually shipped direct to you at the same time that I ship
ClioWeb’s files and manual. If you already have ColdFusion 5.0 or later on your Web server,
then you don’t need to buy ColdFusion from us (but you can if you want). If this applies to you
and you did not already arrange for a don’t-need-ColdFusion discount on your ClioWeb purchase
price, please call us to take care of that.
If you do not have ColdFusion installed on your Web server, please install it now. The installation
instructions and programs that come with ColdFusion are quite good, so there is little that I can
add to them here. I have installed ColdFusion in a number of different environments, so if you run
into trouble, feel free to call me about it and we’ll see if I can be of any help.
Once you have ColdFusion installed and running, go to your ColdFusion Administrator page
(found at http://localhost/cfide/administrator) to test your ColdFusion installation and continue
with ClioWeb’s setup.
Set up ClioWeb’s datasource
ClioWeb needs access to the data in your Clio database. In Web server terms, it needs a
datasource, and we suggest naming it ‘cliodata’. We recommend that ClioWeb sites and their
servers always access a COPY of your real Clio database. We can supply a number of tools to
make maintaining this replica of your real database very easy. Exactly what method you choose to
use to maintain your replica database depends on your ColdFusion version, the OS of your Web
server, network conditions, and ILL transaction volume. There are some general conditions
placed on ClioWeb users deriving from the OS of their Web servers, so I will discuss the options
in that context.
Other, more general datasource issues differ depending on the version of ColdFusion you are
using. Pre-MX versions of ColdFusion relied on OS-supplied ODBC connections for their
datasource access. Linux versions of CF came with their own ODBC engine and drivers for a few
types of datasources. The MX version of CF introduces a new datasource system, called JDBC,
for Java Database Connectivity (or something like that). This system requires you to register
datasources with ColdFusion, instead of the OS. In the case of ODBC datasources on a Windows
box, you need to register the datasource with both the OS and ColdFusion. ODBC datasources do
not appear to be usable on Linux versions of ColdFusion MX, even if you have unixODBC
running on the machine.
Windows servers
You have the most options. The easiest solution is to use Microsoft’s Replication Manager to
maintain a partial replica of your Clio database for ClioWeb to use. (Since ClioWeb only needs
two of Clio’s tables, your replica database might as well only include those tables) To install
Replication Manager, just copy the files in the RepMan folder on your ClioWeb CD to your
server. Start the ReplMan.exe file and a wizard will take you through the process of setting up a
replica set. Complications always seem to arise during this process, however, so it would
probably be best to give me a call before or while attempting to set this business up.
Another option is to use our own ClioDET (Data Export Tool). We originally developed this tool
for our Linux users (although it was soon rendered obsolete). This tool exports the data ClioWeb
needs out of your Clio database and into two text files that can then be used as a text datasource
for ClioWeb via ODBC. The DET consists of three files: an .exe, an .ini, and a .bak file. These
6
ClioWeb 3.0 Manual, version 1
can be found in the ClioDET folder of your ClioWeb CD. Again, it would be best to give me a
call to talk about the issues involved in setting this process up rather than have me describe it all
here.
Lastly, you can use a data access scheme of your own devising. If you really feel secure, you can
have your Web server access your Clio database directly, but I would not recommend doing that.
ClioWeb users have rigged up simple copying routines that produced a copy of the real Clio
database on their Web server every few hours, or once a day in the middle of the night. Use your
own judgement of your network traffic and the degree of need for up-to-the-minute ILL request
information when setting up such a system, and feel free to call me to chat about it.
Linux servers
This is a troubling subject and is becoming the bane of my existence. At the time of this writing
(the first week of September, 2002), we do not have a satisfactory data access solution for users of
ColdFusion MX on Linux, and only a partial solution for CF 5.0 users. However, an all-cases
solution is in the works and should be available by the end of this month.
The problems for Linux servers have arisen from a string of inaccurate information from
Macromedia and Allaire about exactly what database drivers would be included in various
ColdFusion versions. First, Allaire swore text datasource drivers would be included in the
Express version of CF. I was never able to actually check this out, and it was only after we
developed our ClioDET that we discovered these drivers were only included in the purchased
versions of CF for Linux. More recently, Macromedia’s documentation for ColdFusion MX
claimed in several places that drivers for MS Access would be included in its Linux versions. In
the end, they were not, nor were text drivers or the ability to use ODBC. This has left us with no
solution for Linux users at the present time. But! It will be a simple matter to construct a data
export tool for our Linux users as soon as Larry Perkins returns from the UK in a couple of weeks.
We will make a tool that will run on a Windows machine that will copy (via ODBC connections)
the needed data out of your Clio database and into a MySQL database that your Linux-CF server
will have no problems dealing with. If in the future MySQL becomes useless to us, we will easily
be able to change over to another ODBC datasource that your Linux box will be able to deal with.
Put ClioWeb’s folders and pages in place
This is a simple enough matter: put your ClioWeb files and folders somewhere in the document
root of your Web server. You’ll find a folder named ‘Page Files’ on your ClioWeb CD; put the
contents of this folder into a directory under the document root of your Web server. The
arrangement of some of ClioWeb’s pages and folders can be altered, but it’s probably best to leave
them as they are for the moment.
One extra task is to place a copy of the file inputfilter.cfm (found in the root directory of
ClioWeb’s page files) into your server’s ColdFusion custom tags directory. This directory is
usually found in ColdFusion’s installation directory (for example, C:\ColdFusionMX\Custom
Tags). This file is a very useful filtering tool for browser inputs. MS Access is particularly
vulnerable to malicious code placed in form field inputs by hackers, so I am happy to include this
page with ClioWeb. All of ClioWeb’s pages that perform database queries invoke this filter.
ClioWeb’s pages should now ‘function’ to the degree that they can at this point. Try browsing to
the index.cfm file in ClioWeb’s root directory and see what happens (for example,
http://localhost/clioweb3/index.cfm). If you get a page that looks like this:
ClioWeb 3.0 Manual, version 1
7
then everything is working properly so far! If you get some sort of error message, then give me a
call and we’ll track down what is out of order. Don’t be surprised if you get an error message; it
seems like there are always unforeseen conditions and exceptions on Web servers that have to be
accounted for when getting something as complicated as ColdFusion and ClioWeb running.
Assuming all is well, then it’s time to get down to the real work of ClioWeb’s setup: configuring
and customizing ClioWeb’s functionality and appearance.
8
ClioWeb 3.0 Manual, version 1
The Login process
The most important thing to figure out when configuring ClioWeb is to work out how you want
patrons to be matched to specific requests and how you want patrons to log in to your site. These
issues are closely related, so it makes sense to consider them as two parts of the same information
chain. The decisions you make in this area depend both on systems/IT issues and ILL/Clio
workflow issues, so it will most likely be necessary for the ILL staff, the IT staff and me to all talk
together to figure out what arrangement will work best for you. Once again, give me a call and
we’ll talk through the options. But first, a primer on the possibilities…
The Clio database maintains two tables of interest to ClioWeb: the patrons table and the
borrowing requests table. Some Clio users do not maintain a patrons database within Clio and so
their patron table is empty. In all cases, the borrowing requests table is full of individual
borrowing request records. It is ClioWeb’s purpose to show the status of these requests (pending,
shipped, received, etc.) to your library’s patrons. To do so in an acceptable manner, it must show
each patron only those requests that belong to that patron.
The First Option
There are two basic ways individual borrowing requests can be matched to specific patrons. The
most straightforward method is to use Clio’s own patron database and patron-matching function
(the ILL staff people will be familiar with this process). In the real world, however, not many of
our customers actually use this facility to maintain a patron database within Clio. As a result, we
designed ClioWeb to be able to match patrons to requests through other means. More on that
below. For now, I will describe how the patron-matching option works:
When a patron database is maintained within Clio, patron-matching is performed for each
borrowing request. As each request is processed, Clio matches it with a patron in the database or
alerts the staff that it has encountered what appears to be a new patron. When a request is matched
to a patron, an entry is made in the ‘PatronID’ field of the request record that contains Clio’s own
PatronID number for the matched patron, which is an auto-number index field in the patrons table.
This entry is therefore meaningless outside of the Clio program. It is useful for ClioWeb in that
ClioWeb has access to this value if the patron is logged in and authenticated against Clio’s patron
database.
To summarize this option: if you perform patron matching, ClioWeb can work by patrons logging
in and being authenticated against you Clio patron database. ClioWeb will then look for its own
patron-identifying entry in each borrowing request, which is found in the PatronID field of each
borrowing request record.
The Second Option
The other option is to use ‘some other’ login process. ClioWeb has two other login processes
built-in in addition to the process described above. The two built-in options are to have no ‘real’
authentication process during the login to ClioWeb, or to setup a bypass of ClioWeb’s own login
process if you have an authenticated area of your website that you can ‘nest’ ClioWeb inside of.
Other login options could be an LDAP server, or a library circulation system’s table of patrons.
Whatever the patron information data source, the way that Clio and ClioWeb will track patron-torequest matching remains the same: a ‘PatronID’ value must be included in the request when the
request is created (and presumably sent to OCLC). Exactly what piece of data you choose to make
your PatronID is up to you. Popular choices include Campus ID numbers, library card barcode
numbers, email addresses, or SSNs. Whatever piece of info you choose, the critical thing is to
make sure it is consistently included in every request. The best way to do this is to make your
PatronID value a required field on your ‘new ILL request’ webform or paper form. That value can
then be included as the ‘PatronID’ value when the request is produced with OCLC. When this is
done, whatever value you send as the ‘PatronID’ ends up in the Patron1 field of each borrowing
request as subsequent messages from OCLC about that request are received.
This point sums up ClioWeb’s login and authentication option number two: ClioWeb will look in
the Patron1 field of each borrowing request for the Patron ID. Whatever the method or source
ClioWeb 3.0 Manual, version 1
9
used for authenticating patrons, ClioWeb will end up with a PatronID value and look for requests
in the BorrowingRequests table for items with that value in the Patron1 field (among other things).
Things to think about when considering this option are:
•
What data sources does my web server have access to?
•
How hard would it be to perform a one-time data dump of patron information into my
Clio database for some other data source? You could then switch to the first option
described above. Since Clio’s database is open and easy to deal with, this usually is not
difficult.
•
What data can I reliably collect from my patrons to use as my PatronID value?
•
Would I be willing to have a non-authenticated ClioWeb site? In that event, people
would log in using two pieces of data, one of which would be used to search the
borrowing requests table. No names or personal info would be displayed, but if the piece
of info you use as your PatronID is freely available, your site’s privacy would be
compromised.
•
Do I have a ‘My Account’ or similar authenticated area of my website that could pass my
ClioWeb site patron-identifying information? In this case, ClioWeb’s own login process
could by bypassed. Arranging this kind of setup can be fairly complicated or, in some
cases, impossible, but is great when it works.
This is a big subject with serious implications for your ILL staff’s workload, so consider it
carefully. But keep in mind that you can always rework how your ClioWeb site works later, so
don’t dwell on this topic too much.
ClioWeb’s settings.cfm page contains several settings that relate to the login process. The most
important one, called “UseDBAuthentication”, corresponds to the switch between the two basic
tracking methods described above. If set to ‘yes’, ClioWeb will look for the patronID value
obtained during login in the ‘PatronID’ field in the borrowing requests table. If set to anything
else, ClioWeb will look in the Patron1 field.
And now, on to playing with ClioWeb itself…
10
ClioWeb 3.0 Manual, version 1
Setup and Configuration
Some ColdFusion Basics
Before we get started, I thought I would include a brief primer for those not familiar with
ColdFusion code.
ColdFusion pages are properly termed ‘templates’ since they are general layouts for Web pages
that can be dramatically different depending on variable conditions encountered at process-time.
They are written in CFML, which is the same as HTML, but with a whole extra library of tags that
call upon ColdFusion’s tremendous capabilities. These extra ColdFusion-specific tags all begin
with CF: hence <CFMAIL> </CFMAIL> tags contain attributes and surround areas that deal with
email functions. <CFQUERY> tags contain SQL queries to datasources. <CFIF> and
<CFELSE> tags act as if/then switches. <CFABORT> tags stop page processing at the point
where they are encountered. ClioWeb makes extensive use of <CFINCLUDE> tags, which
instruct ColdFusion to include the contents of another file at the point where they are encountered.
Variables are indicated in ColdFusion pages by the use of hash marks. This code:
#FORM.patronname# <BR>
Would be produce line of text with the value a form field called ‘patronname’ that was passed to
the page. You can specify form, URL, cookie, session, and other types of variables when calling
them in ColdFusion code. These variables should usually be placed within <CFOUTPUT>
</CFOUTPUT> tags, which define areas that ColdFusion examines for variable processing.
Variables can be used in SQL statements, and can be given new values as many times during a
page’s processing as you like.
Another great feature of ColdFusion processing is the ability to put hidden comment blocks into
page code. Standard HTML comment tags look like this:
<!-- here is the comment -->
ColdFusion comments look like this:
<!--- here is the CF comment --->
The difference? An extra dash in the start and end tags. This is a crucial difference, however,
because it causes ColdFusion to strip out that comment block before it sends the page to the
requesting browser. This means that you can put very descriptive comments into your page code
that would otherwise be unacceptably revealing to potential hackers.
Navigating through and figuring out ClioWeb’s code should be fairly intuitive to anyone familiar
with HTML and/or any other Web application system. ColdFusion is so easy to understand and
use that I feel guilty sometimes.
There is a special file name when it comes to ColdFusion applications: it is Application.cfm.
Every time a ColdFusion page is processed, ColdFusion looks in the same directory and then up
the directory tree structure until it encounters a file by this name (or runs out of Web directory).
This file is therefore a great place to put application-wide settings and preferences. ClioWeb 3.0
has an Application.cfm that is in a different place and performs a much different function than
previous versions.
Some ClioWeb conventions
Every ClioWeb page (with just one or two exceptions) includes a comment block at the tope of the
page code that includes the page’s name, a description of its function, the author (me), its date and
version, a notes area, and a mention of any other files that are included in the page.
Pages that visitors will see are generally given names that begin with a capital letter. Non-visible,
‘infrastructure’ pages are given names that being with a lower-case latter.
ClioWeb 3.0 Manual, version 1
11
ClioWeb pages use included files to separate the engineering and appearance parts of your pages.
All ‘visible’ ClioWeb pages include a fairly standard arrangement of included files. All included
files are simple .txt text files. These are easy to deal with and most hackers would not suspect that
they are there. These files are treated as regular HTML in the pages where they are included.
They are intended to contain most of the look-and-content customizations that you will make to
your ClioWeb site. This makes it much easier to customize your site, as you don’t have to sort
through hundreds of lines of ColdFusion code just to find the place where you office hours are
listed on your ‘welcome’ page, for example. The .txt files all begin with the name of the ClioWeb
page that they are included on, and reside in the same folder.
Feel free to alter this arrangement as you customize the look and content of your ClioWeb site. As
delivered, however, each page includes a text file in the <head> area, making it a good place for
stylesheet specs, if that’s what your site uses. This file also includes the <body> tag, making that
crucial tag easy to find. Each page includes the generic PageTop.txt and PageBottom.txt files,
useful as site-wide page header and footer files. Each page then includes at least one file in its
body area intended to contain the majority of the content that you will want to add to the page.
Restricting your modifications to your ClioWeb pages to these files as much as possible will make
it a lot easier to update your ClioWeb site in the future, so for your own sake please do your best
to make do with what these included files allow.
Configuring ClioWeb
The 3.0 version of ClioWeb introduces a new architecture, login tracking process, and a
centralized settings file that makes configuring ClioWeb a whole lot easier than it used to be.
ClioWeb’s structure
ClioWeb consists of a ‘root’ level folder, an ‘Inside’ folder that constitutes the secure area of the
site, and two other folders that can be put elsewhere or live in the root folder alongside the Inside
folder. The latter arrangement is how ClioWeb comes on the CD. In the following few pictures,
ClioWeb’s structure is illustrated:
Here the ‘root’ folder’s contents are displayed. The only things that really need to stay in this
arrangement are the files in this folder and the contents of the Inside folder. Your links from your
website into your ClioWeb site should point to the index.cfm page in this folder, wherever it may
be. For example, a common URL that people put their ClioWeb site would be something like this:
http://www.college.edu/library/ILL/index.cfm
12
ClioWeb 3.0 Manual, version 1
If you configure index.cfm as a default document on your Web server, the trailing index.cfm in the
URL would not be needed. You could also nest your ClioWeb site inside a frameset, concealing
from the average visitor that your site is a ColdFusion application.
The login and logout pages are contained in this folder, as are Application.cfm and settings.cfm,
two pages that are included in every ClioWeb page. A site-wide error page that you can use if you
want to is also included: cwerror.cfm.
The Inside folder contains the ‘meat’ of the ClioWeb site. Here you will find Menu.cfm (a ‘main
menu’ page) and Results.cfm, the page that performs the search of your Clio BorrowingRequests
table and displays to the visitor the status of their ILL requests. Authcheck.cfm is included at the
top of each of the pages in this folder: it is the ‘gatekeeper’ for this folder ensuring that everyone
requesting a page in this folder has successfully logged in. Reqform.cfm is a generic new-ILLrequest form page that you can use if you want to, or you can continue to use whatever request
form/s you have now. Mailform.cfm is a general-purpose “I have a question or a problem” email
page. ViewPDF.cfm is the page that gets visitors access to whatever PDF files may be waiting for
them to view (more on this later). Mailer.cfm is the unseen page that handles sending emails from
the other pages in this folder.
The ClioPDFs folder is intended to contain the PDF files that are have been converted by the
EDelivery module and are waiting to be viewed by patrons. This folder can be moved or renamed,
as its location and name are set in settings.cfm (more on that later).
ClioWeb 3.0 Manual, version 1
13
The ‘admin’ folder I included only to separate the file it contains from all of ClioWeb’s other
pages. Read the notes included in this page’s code carefully! It is designed to be run as a
ColdFusion-scheduled task on your server that will clean out your ClioPDFs directory. The
settings that control it behavior are in settings.cfm. It does not ask questions or display anything,
all it does is delete files with a .pdf extension older than a date limit that you sepcify. Don’t run it
unless you are sure everything is set properly!
settings.cfm
Everything you will need to specify concerning ClioWeb’s functionality is contained in this one
file, found in ClioWeb’s root directory. It is very well-commented and as self-explanatory as I
could manage, so just read through it and set things according to your environment.
14
ClioWeb 3.0 Manual, version 1
‘Infrastructure’ pages
As mentioned earlier, ClioWeb contains a number of pages that function in an ‘unseen’ way by
performing email functions or containing site-wide settings. A description of each follows.
Application.cfm
This page is processed before and as a part of each ClioWeb page. It invokes the ClioWeb
application. It also creates and specifies the timeout for the Session variables that are used to track
each visitor’s login status. It also includes a line of code that specifies cwerror.cfm as the sitewide error page for your ClioWeb site. This line of code is commented-out as delivered so that
you can see error messages while you are setting up ClioWeb. Once you have made you site
‘live’, I suggest you un-comment this line of code so that visitors do not see any revealing error
messages in the event of an error of any kind.
settings.cfm
This file is included by Application.cfm and so is included in every CW page. It contains all
functionality-related settings in ClioWeb.
inputfilter.cfm
This page is included as a custom tag in all of ClioWeb’s pages that run database queries. A copy
of this page should be placed in your ColdFusion’s Custom Tags directory. It filters out any
potentially malicious browser input that could cause unintended database actions.
mailer.cfm
This page handles the three types of emails that ClioWeb can send. Each type of email (new ILL
requests, renewal requests, and general purpose) has its own section bounded by <CFMAIL>
</CFMAIL> tags. The format within those tags should be self explanatory once you’ve had a
look at the emails they send.
authcheck.cfm
This page is the login gatekeeper for the Inside folder. If in encounters a visitor with an improper,
expired, or absent login value, it sets a ‘login problem’ variable and then includes Index.cfm,
bypassing the requested page from the Inside folder. Index.cfm looks for this login-problem
variable and displays a message indicating to the visitor that they were intercepted and should log
in again.
deleter.cfm
This page is the PDF-directory cleaner. It deletes all files in your PDF directory older than a
number of days-old that you set in settings.cfm (as well as the location of your PDF directory). It
has a <CFAUTHENTICATE> tag at the beginning of the page’s code that is commented out as
delivered. When you set this page up in your ColdFusion Administrator to run as a scheduled
task, you can include a username and password for the file. You can set the same username and
password in the <CFAUTHENTICATE> tag to ensure that this page does not run accidentally.
ClioWeb 3.0 Manual, version 1
15
‘Visible’ pages
General page construction issues
Each of the pages that a visitor to your ClioWeb site might see includes a number of consistent
features. Each page includes several text files as delivered: one in the <head> area, common
PageTop and PageBottom files, and at least one page-body file. These files are intended to
contain most of the appearance and content modifications that you will need to make to your site.
Your ClioWeb pages come to you in an essentially ‘blank’ state. As an out-of-the-box website
solution, I can do the engineering for you but I can’t deliver you the content. I am more than
happy to help you get your site looking like you want it to once you have it running, but I can’t
really send it to you that way.
As delivered, I have put one-cell tables with a blue background and yellow text into each of the
visible included text files so that you will know they are there and where they appear in the page
that includes them. Be aware that there is also a header-file for each page that is unseen, but
which contains the <body> tag for each page.
Index.cfm
This is the ‘welcome’ page to your site. This is a good place to put things like your office hours,
general ILL instructions and policies, and the like if you are going to use ClioWeb as the whole of
your ILL website. If ClioWeb is going to remain an ‘extra’ aside from the core of your ILL
website, then you can leave this page mostly blank. If you are going to bypass ClioWeb’s own
login process, then people won’t ever see this page and you can discard it.
There is a ‘click here’ link on this page that executes a Javascript that launches a login window
containing cwlogin.cfm.
cwlogin.cfm
This is ClioWeb’s login processor. This page is launched into its own window by a script on
Index.cfm. In the course of performing a login, this page is loaded three times. If a login is
successful, on the third time cwlogin.cfm loads a new page in the ‘main’ window where Index.cfm
has been waiting and closes its own window. In that way, the login process is gone, so noone can
16
ClioWeb 3.0 Manual, version 1
‘go back’ to it to attempt to log in again using someone else’s information or attempt to hack the
process.
You can configure the size of this window when it appears in Index.cfm. The labels for the two
text boxes are set in settings.cfm, as are the database fields that they correspond to when the
authentication query is run. There are no included files in this page as delivered, since I think you
should talk to me if you plan to alter this page.
Menu.cfm
This page is where ClioWeb visitors are taken to after a successful login by default. You can
change the successful-login target in settings.cfm if you don’t need or want a menu page like
Menu.cfm.
It’s content is pretty simple. You can turn the link to the ‘send us some email’ page
(Mailform.cfm) on and off with a setting in settings.cfm.
ClioWeb 3.0 Manual, version 1
17
Results.cfm
This page is the crux of the ClioWeb biscuit. This is where people go to see the status of their ILL
requests and view documents that have been received via Ariel. The example below is what you
will most likely see the first time you go to this page, when you will most likely have no matching
results:
In this case, a specific .txt file is included where you can put a ‘no items’ message and
explanations about why items visitors might be expecting to see might not be there.
If a visitor does have items to see, they will get a page like this:
18
ClioWeb 3.0 Manual, version 1
A ‘you have results’ text file is included, followed by a small table for each item to be displayed.
Information appropriate to the item type is displayed. For items that are not articles, are not
overdue, but have been received and have a due date, a ‘Request Renewal’ box can be displayed,
along with a ‘Send Renewal Requests’ button at the bottom of the page. You can turn this feature
on and off with a setting in settings.cfm. If it is on and a patron submits a renewal request, an
email is sent to an address you specify in settings.cfm with the item/s information and the patron’s
patronID value.
ClioWeb 3.0 Manual, version 1
19
If a patron has an item that has been processed by ClioEDelivery and should be in ClioWeb’s
ClioPDFs folder, a special message is displayed with a link to ViewPDF.cfm:
Several of these links might be displayed for an individual patron. Clicking on any of them will
take the patron to ViewPDF.cfm
ViewPDF.cfm
This page runs another query to confirm the ILL items that should have corresponding PDF files
awaiting the patron in your ClioPDFs directory. It then compares this list with files that are
actually present in this directory. Only files that are present in both lists are displayed to the
patron. Ideally, these lists should always match, but accidents happen.
There are two body-content text files included on this page. They are given names reflecting the
two messages you are likely to want to give your patrons on this page: that they will need Acrobat
Viewer and whatever copyright restrictions statement you want them to agree to.
Patrons can use buttons at the bottom of the page to go back to their list of items, back to the main
menu, or log out.
20
ClioWeb 3.0 Manual, version 1
Reqform.cfm
Reqform.cfm is a generic new-ILL-request form page that you can use if you would like to. Most
institutions already have form pages that they have spent a lot of time on, so don’t feel obligated to
use mine. The nice thing about my page is that it fills out the patron’s information for them if that
information is available.
The form contains the ‘stock’ bibliographic fields available in Clio, ClioRequest and OCLC
messages. This page is nothing special; modify it to your heart’s content.
Mailform.cfm
This page is included as a general-purpose “I have a question and/or a problem” email form page.
You can turn access to it on and off with a setting in settings.cfm.
ClioWeb 3.0 Manual, version 1
21
As with the other email-sending pages, the format of the emails it sends is handled by mailer.cfm,
and the address it sends mail to is set in settings.cfm.
Cwlogout.cfm
This is the page visitors are taken to upon clicking any of the ‘log out’ buttons. This page
removes the patronID session variable that was placed when the visitor logged in (if present). It’s
a good place to put links to other parts of your site. If you minimize the presence of links to other
parts of your site in ClioWeb’s other pages and the only ‘out’ option they see is the logout button,
then people might be more likely to actually use it and log out properly, which is a good thing to
encourage.
22
ClioWeb 3.0 Manual, version 1
cwerror.cfm
This page can be used as a site-wide error page for your ClioWeb site. There is a line of code in
Application.cfm that invokes this rule. This line is commented-out as delivered so that you can
see valuable error messages while setting up ClioWeb. Un-comment this line when your ClioWeb
site goes live so that hackers and library directors don’t get to see those messages in the future!
ClioWeb 3.0 Manual, version 1
23
Copyright Notice
© Clio Software. All rights reserved.
This manual, as well as the software described in it, is furnished under license and may be used or
copied only in accordance with the terms of such license. The content of this manual is furnished
for informational use only, is subject to change without notice, and should not be construed as a
commitment by Clio Software. Clio Software assumes no responsibility or liability for any errors
or inaccuracies that may appear in this manual.
Except as permitted by such license, no part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or by any means, electronic, mechanical, recording, or
otherwise, without the prior written permission of Clio Software.
Clio and ClioWeb are products of Clio Software and are trademarks of Clio Software in the USA
and other countries. Microsoft, Windows, Windows NT, Windows 2000 and Microsoft Access
are registered trademarks of Microsoft Corporation. ColdFusion and ColdFusion MX are
registered trademarks and Macromedia and the ColdFusion logo are trademarks of Macromedia
Corporation. All other products or name brands are the trademarks of their respective holders.
24
ClioWeb 3.0 Manual, version 1