WebWare 1.0:The Old Framework
January 25, 1999
In 1994, Selena Sol and Gunther Birznieks were doing just that - writing
lots and lots of code! By the time they had completed their third
proprietary web store, they realized that this web application
development model needed to be streamlined.
To do so, the two began to write modularized, generic web
application "cores" that could be more easily molded and remolded
from one project to another.
Rather than adopt proprietary languages/environments such as
Cold Fusion or NetObjects,
Perl and
Java were chosen as the
languages to be used. They were chosen because of their ease
of use and wide-spread appeal. Ease of use was important because
we wanted the applications to be accessible to both beginning
and advanced developers. "Wide-spread appeal" was important
to allow the applications to benefit as wide an audience as possible.
|
NOTE: Now we want to be VERY clear that we have nothing
against proprietary solutions for web application
development. For instance, we think Cold Fusion is an
excellent product by itself.
In fact, we consider the company to be one of the coolest
pioneer/revolutionary organizations on the web.
Coding in a proprietary environment may often be the best
solution to a specific problem.
However, when we were designing our code, we were interested
in writing code that would be useful to the masses of
web users who might not have
access to these, often expensive, technologies.
Such clients might include "Joe Web" who has a standard
internet account hosted by ANY_ISP_USA. ANY_ISP_USA
probably offers Joe CGI
functionality but not a personal RDB or application
development environment like Cold Fusion.
But this made sense for Joe since not only
could he not afford such extras, but he would not
know what to do with them. Joe is in the
business of selling widgets on the web, not
programming or database administration. Joe
should have a solution that meets his needs.
We also wanted to develop an open standards protocols for
developing applications that could be used as a springboard
for other developers not even associated with us. We hoped
to provide a foundation upon which others could build without
fear of our pulling the code out from under them.
|
This process of genericization and modularization involved
three stages:
- Extracting user interface code into
HTML configuration
files
- Extracting Programmatic Intelligence into application
setup files
- Documenting the hell out of the code.
Extracting the UI Code
Essentially, any code that sent
GUI
(HTML or
Java) data to
the user was extracted from the application and placed in
a GUI configuration file.
The great benefit of this was that when the
GUI
code was
separated away from the main code,
a user unfamiliar with application programming,
but familiar with basic
GUI
programming such as
HTML could
modify the user interface code without worrying about
breaking the program.
After all,
GUI
code tends to change more often between sites
than other types of code. Every web site tends to have their
own specific look-and-feel.
In addition, separating out the
GUI
allowed users to apply bug fixes without deleting their GUI
changes. Since program logic was separated from GUI logic, a fix
to the program logic did not require the user to redo all their
GUI/
HTML
changes every time a new version came out.
Here is an excerpt from one such
GUI
configuration file.
sub required_fields_error_message
{
print "Content-type: text/html\n\n";
print qq~
<HTML>
<HEAD>
<TITLE>Error in Processing Form -
Required Fields</TITLE>
</HEAD>
<BODY BGCOLOR = "FFFFFF"
TEXT = "000000">
<BLOCKQUOTE>
<H2>
Woops, I'm sorry, the following fields
are required:
<UL>
<LI>Name
<LI>Email
<LI>Comments
</UL>
Please click the "back" button on your
browser or click <A HREF =
"$url_of_the_form">here</A> to go
back and make sure you fill out all
the required information.
</H2>
</BLOCKQUOTE>
</BODY>
</HTML>~;
}
sub cannot_find_database
{
print "Content-type: text/html\n\n";
print qq~
<HTML>
<HEAD>
<TITLE>Form Processing Error -
Database Access</TITLE>
</HEAD>
<BODY BGCOLOR = "FFFFFF"
TEXT = "000000">
<H2>
<BLOCKQUOTE>
I'm sorry, I am having trouble finding
the database that this information should
be sent to. Please contact
<A HREF = "mailto:$email_to">$email_to</A>
and let us know that there has been a
problem. Thank you very much and sorry about
the inconvenience.
</BLOCKQUOTE>
</H2>
</BODY>
</HTML>~;
}
You can see how
HTML-like the code appears. We found that
by extracting out the code like that, users were much less
intimidated with making changes.
This separate
GUI
code could be imported into the
main application code using
Perl's require or use keywords.
Then, the GUI-specific routines could be called from there.
Extracting Programming Logic
Extracting implementation-specific programming logic was the
next step in the Extropia scripts evolution.
We knew that we would have to provide a host of services for
each application that could be
turned on or off depending on what services
each installation would support. To do that we needed to
write the methods into the base code and then provide the
user with "switches" in an application setup file.
A user need only specify the general workflow of the application by
answering "questions". Below is an excerpt from such a file:
$should_i_email_orders = "yes";
$should_i_use_pgp = "no";
$should_i_append_a_database = "yes";
The actual code would check for each case and act accordingly
using "if tests" such as:
if ($should_i_email_orders eq "yes")
{
Go ahead and mail;
}
else
{
Don't mail didilly squat;
}
The trick was to predict all the myriad ways the script
might need to function, build in that generic code, and
finally provide "should_i" options in the configuration file to
activate the relevant code in the main application.
Documentation
Finally, the remaining code would have to be documented intensely
so that a developer could easily come in to make site-specific
modifications. Note that we did not want to be in the business of
installations and customizations, we wanted to provide
extensible source code so that others could do that.
The Result: Limits of the Model
We had a great deal of success with this streamlined web
application development model. Thousands of sites implemented
the code and found that they never needed to do anything
beyond editing the
HTML in the
GUI
definition file.
However, within a couple
of years, chinks in the model became more apparent.
For one, it was hard to organize group programming projects
such that add-ons were easily transferred to the entire group.
The code needed to be far more "Lego-ized" for that to happen.
That is, there needed to be a way to easily disassemble
code and re-assemble it in different configurations with
very little effort. Similarly, new and more efficient
routines should be easily "popped" into existing applications
without breaking the old routines that depended on it.
We had modularized the
GUI
and implementation specific setup
information, but we still needed to modularize the internal
generic algorithms. Once these algorithms were modularized,
a more efficient, secure and robust algorithm could instantly
replace an older algorithm in the main code without breaking
it. Likewise, services such as data access could be more
easily modifiable such that a user could easily move the
code back and forth between databases such as Sybase or Oracle.
What exactly are Web-Applications?
Extropia WebWare Suite 2.0: Towards a New Application Development Framework for Server-Side Web-Based Applications in Perl and Java
Moving to Object Oriented Design with Perl 5 and Java Servlets
|
