Talking Shop
One might generalize that the intent of modern programming practices is to create a library of reusable code components – a “toolkit” of sorts that speeds development of future applications. My experiences in developing for the Web have taught me that such a toolkit doesn’t need to be large to be effective. It is possible to create a powerful Web application framework using only a handful of code files.
Think of a Web application, at the technical level, as being composed of four basic elements:
1. A data store
2. Generic code components that may be shared with other applications
3. Application-specific code
4. The graphical interface
The more capable and well thought out your number two elements are, the simpler the threes and fours become for every new application you build.
At the functional level, there are only two parts to a Web application: forms and views, or, alternatively, input and output. With this in mind, we can say that the most useful generic components are ones that store and retrieve information.
XML reporter
This component would take a SQL query as a parameter, and return the results from the database formed as XML. The XML document would have a record element for each database record, and a sub-element named for each of the fields:
field one data
field two data
HTML form processor
The form processor loops through each of the form fields submitted, writing their values back to the database field with the same name. If the primary key already exists in the database, the form processor performs an update operation on that record. Otherwise, a new record is created.
To display information from the database in a Web page now requires very little application-specific code. Simply create a dynamic page (JSP, ASP, etc.) that passes the appropriate SQL query to the XML reporter, and transforms the returned XML using an XSL template (note that by performing this transformation server-side, plain HTML is returned to the client and browser support for XML is not required). In addition to ease of development, this also presents the advantage of having your presentation code (graphical interface) completely isolated from your application code. Building a new application involves little more than creating the fields, the query statements for different views, and the XSL for formatting.
The usefulness of this framework becomes even more apparent when round-tripping information from the database to a Web form, and then back to the database. To create a form that displays a record for editing, follow the same process as above, but use the XSL template to display the data in HTML form elements. After all, a form is really just a view that can be edited. Store the table name and primary key in hidden form fields, so that they are passed to the form processor along with all of the data fields when the form is submitted.
But, what if…?
This framework is clearly not a panacea when dealing with more complex applications. Its strength is in the simple viewing and updating of data via the Web. The form processor, as it is described, will not be a very good fit for applications that don’t update that database unless certain conditions apply. Perhaps in these cases a generic form processor could still be used, but would require the additional functionality of checking an XML file of business rules before performing write/update operations, or ( insert your own creative solution here).
As a programmer, I don’t look for a one-size-fits-all solution, but I do continually ask myself “Is there a way I can do this more generically?” Developing a scalable solution means being able to see the big picture, rather than just the microcosm of a single application.
I’ve tried to describe this framework in a way that is platform-neutral, but please feel free to e-mail me if you’d like to discuss a language-specific implementation.
Cooney works as a programmer/analyst for a major Canadian book publisher. He can be reached at robert_cooney@hotmail.com.