In the past, we had a paper diary, and you would ring up the booking clerk to book the resource, but we needed a system on the Web.
We have about 200 bookings a year, and it had to be up and running within 3 months.
My BTInternet account, has a guest book, which allows people to post comments about my web site. What we needed was a ‘guest book’, but one that was sorted by resource and date. Our members would look at the guest book, book the resource, and the system would warn them if the resource had already been booked. Simple!
Oh and it had to have an audit trail, as we needed
to bill the members for their usage at the end of the season.
My starting point:- I had a BTInternet Web site and
had played with AWK based CGI scripts
on the group’s unix server in 1995. I did not know anything about web hosting,
and I am not a UNIX guru 1st Dan.
How do you collect booking requests using a guest
book and sort them by date?
Well, if BTInternet provided a guest book that saved
the form submits in a way that a web page could process and sort it, I could
achieve my aim in a few evenings work.
The idea: Wrap the form data in
JavaScript Function calls and append to a file of JavaScript. Include this file
when I download my web page. The
generic CGI script also escapes any characters that would cause the data to
clash with the code.
It would allow me to write this application and
BTInternet would not need to allow a full CGI access, and was very similar to
the existing guest book with regard to security.
I would not need to learn all about the server side
stuff.
Our club is a do it yourself club, we look after our
boats, and we train our members to use them and we do it voluntarily.
There were loads of community groups, that have
shared resources to book, but are all slightly different.
Around
the office and groups of people there are many little jobs that could be put on
the web, if only we knew how. There is a BIG learning curve. This puts people
off.
Windows
98 comes with a webserver, IIS,
and an example that uses Access 97. It
is very complicated, and as anyone of our members could be maintaining the club
site, reliance on Access 97 is unacceptable.
You
can summarise many applications as, Select, Sort, Select, Display, Part fill a
form and allow users to update part of the information, append the information
for future users.
The
table below summarises typical applications.
Application |
Sort By: |
Select By: |
Display |
Users can update: |
Booking diary |
diary, submit order |
last amendment. |
Last update, popup history. |
1) Amend an existing booking, Add a new booking. |
Document index |
Document Number, Issue number |
all |
All, history as popup history. |
1) Auto allocated a new document number. 2) Add a new issue, Change the title. 3) track issue status and location. |
Sports League Score table |
League, Positions, Played, |
Leagues, |
Leagues. Scores, Names. |
1)Add new members, Users add results, |
Team Roster, Availability |
Match/Event, Player, amendment. |
Latest for player |
Match, Players, |
Member can state which periods they are available |
Simple fault Logging system |
Fault ref, |
Latest, popup history |
List of faults, status |
1) Allocate a new fault number, add title. 2) Append updates to each fault. |
Model Build Register |
Model, Build loaded date |
Latest, popup history |
TimeLine or Models, or load date, |
Load date |
Use
a database on the web server! I hear the cry. The database should be on the
server, and you need a server-side language to interface to it.
There are a number of solutions. The Microsoft way:- IIS webserver, ASP, Microsoft Access 97 based database. Another popular way is an Apache webserver, PERL or PHP interface language and a MySql database.
But
I only need 200 transactions per year, and I need the audit trail, so the present form, sort, select, display,
part-fill form and allow partial update was the solution.
I started with a BT guest book, and copied the entries into a form field, and processed it using JavaScript. Then I downloaded PHP, and MySql, and set up web servers on my PC at home. I was inundated by a tidal wave of web oriented help pages, and much work just to get to the same starting line. Then I found that what I could do in JavaScript, I would need to do in ASP, or PHP, only with another yet to be learnt syntax.
I
need to open a file, sort the data, do some string manipulation on it and
present it, wrapped in HTML tags, to the user with a form, for them to update.
I needed to validate the form against the existing data.
A conventional database application can be
summarised by:
Normally middleware like PERL, ASP, PHP
interfaces to the database. SQL selects, and sorts, while the middleware adds
the HTML to format for display on a web browser.
My idea is this: Use a generic server-side
script to append the submitted data from the form, as parameters of a
JavaScript function, onto the end of a file. This is included as a normal page
download. All the sorting, selecting and formatting is done using JavaScript on
the client's browser.
Although JavaScript still requires some
programming skill, any novice programmer who has a PC with IE5 or Netscape 4.5
has a development environment sufficient to start work. They also need a simple
graphics program and HTML editor to provide a good start.
A good HTML / JavaScript cookbook and a good
reference is also very useful.
All the sorting, select and formatting is
done using JavaScript and HTML and is enough to put together simple web
applications.
You need a good generic server side script,
provided by your webhoster that appends
the form fields wrapped in JavaScript function calls to a file in your web
hosted space.
You have to be happy to include this file of
JavaScript function calls in your web pages, and how to use some 'simple'
JavaScript to sort, select and output HTML to summarise and present the data.
Given a nice looking page created by a Web
Page creator application, and an understanding of HMTL, it is simple to cut and
paste the HTML into JavaScript, so that the output is data driven by the data
submitted on the web forms.
You may give your users explicit access to
the update form or the form is hidden and only invited users are given access
to these pages.
We have avoided the need to set up Web
servers, a server side environment, and
a database, all of which require learning.
We do not need to tackle a large number of issues
that normal web designers have to address just to get anything working.
Typically these could be:
· UNIX / LINUX for PC literate people.
· File and execute permissions, alien to PC literate people
· Accessing MySql or Access databases, from perl, ASP or PHP
· Learning about SQL and relational databases.
· An Entity Relationship design - you are constrained to appending
a generic form format
· Learning Perl, ASP or PHP as well as HMTL, and JavaScript
· Using Telnet and UNIX/LINUX commands to view the error logs on
the server
· Learning how to open files, append strings, etc in half a dozen
languages
· Spending lots of time, on line, bug fixing simple configuration
issues
· Trying to understand how your webhoster has set up their server,
and replicate it on your model server.
Later on, you can acquaint yourself with the
knowledge to set up a more robust server side application. At first, your
database could serve the data to your pages wrapped in JavaScript Function
Calls as inline data.
I invented this to provide a pragmatic
solution for the Sailing Club to satisfy a real need.
Commercially, getting the solution to market
was more important than an enterprise scaleable solution. We expect about 5000
page hits and only expect about 200 to 300 transactions/submits per year!
This is a difficult question, especially when they give free space, and free downloads. My ISP limits web hosting, such that the page owner has to upload pages via a dial up connection. This idea would allow the website owner to allow anybody to upload 'content'. If the generic CGI script referred to a credits file, every time the script is run, it could use up some of the credit. After a number of uses, the script uses all the credit up and stops functioning, until the credit file is refreshed, by the site user dialling in at their cost.