Here live some of my thoughts on web application development, especially the technologies used therein. Naturally, this pseudo-essay has tie-ins to WebPython and its development.

1.2.1 Spectra

As in all things, web applications range in complexity, from simple one-off applications to enterprise-scale systems. And with the level of program complexity, the level of development tool complexity increases; the range spans PHP and J2EE alike.

But both PHP and J2EE have a certain rigidity of structure which makes them wonderfully suitable for certain types of applications, and less suitable for others; there is middle ground between them. Though this middle ground exists, it is woefully under-exploited. Many applications are shoehorned into entrenched technologies that are entirely inappropriate to the complexity level. One can write an inventory tracking system for thousands of locations in PHP, just as one can write their blogging program in Java, using J2EE. But neither is a good use of the respective technology.

And that is where I feel the toolkit enters the scene: between the two extremes.

1.2.2 General Purpose

I feel the need exists, in the world of web applications, for technology that is flexible, that changes shape to fit the application and the developer. And this flexibility, I feel, is found with toolkits that can be used as libraries; that is, modules imported and used within the scope of a program.

Take, for example, database access. On the very simple level, we have functions that connect to a user-specified database and execute user-specified SQL statements. On the very complex level, we have object-relational mapping frameworks that require extensive user configuration, but have the benefit of generating ready-to-use objects and removing the necessity of SQL.

But between these, wouldn't one think that there is room for a module which simply connected to a user-specified database and returned a representational object? Perhaps this object could possess methods analogous to common database actions, sub-objects representing tables, and even a method to execute user-specified SQL.

This way, developers, no longer needing to write SQL statements, can concentrate on the "business logic" of the application. But if it's really needed, they can still run custom queries. And all the while, there is no need for any configuration beyond specifying connection parameters when loading the database. Nor is the namespace polluted by numerous database-related functions. This is indeed flexibility of an uncommon kind.

The world would be a better place (in terms of software development) if developers demanded more flexibility and general-purpose applicability in the tools they use.

1.2.3 Buffet

No matter how flexible and general-purpose a toolkit (or any technology) there is limited practical use if it is really useful for only one style of development, or if it does not allow developers to pick-and-choose which parts to use. Unfortunately, with a framework, one needs to buy into the whole package, to do things in very specific ways, which are not necessarily portable among other technologies.

However, a good (well-designed) toolkit requires nothing more than the obvious use of the provided functions, if one chooses to use them at all. It is this aspect, this mix-and-match approach, that is so woefully missing from so many other web application development tools. When I wrote WebPython, one of my goals was to acheive this, and as such, have the whole toolkit properly compartmentalized and modular.

And in the future, as changes are made and features added to a toolkit, it should not be allowed to "grow organically." The original structure should be adhered to strictly; modularity must be preserved, or the usefulness of the toolkit approach is compromised. Then one has something much like many of the already-existing ad hoc development tools.

1.2.4 All Together

So what do we get when we combine the above, the middle-of-the-road complexity with the general-purpose applicability with a modular design? Why, the end result is a useable, well-designed toolkit. One from which a developer can choose whatever parts they wish to, while leaving the rest. One which is appropriate and easy to use for a vast range of problems.

This is the overarching goal I had in mind when I set out to write a toolkit that I could use for my logbook. I wanted to write something I could use again, even on a completely different project, something globally reuseable that would make web application programming simple.