I have a big collection of modules that are currently under the JCS::
namespace (my initials). Together, they are meant to form a sort of web
application construction kit. They're still under development, but I intend
to release them to CPAN eventually. I'm also considering releasing parts of
the suit as they get closer to completion.
The modules are largely interdependent, although some subsets can exist in
isolation. But all such subsets start from the lowest-level modules and go
upwards in abstraction. Here are the major parts of the suite, roughly from
the bottom up:
* An object base class plus a simple method maker
* A URI class
* A set of DateTime utility functions
* HTML objects (form objects)
* A DBI wrapper
* A library of SQL manipulation and generation functions
* A db-backed object base class
* A basic web application framework
* An MVC-style web application base class
First, a brief defense of a few of the things that seem like wheel
reinvention:
* A URI class - It actually uses the existing URI class, but stores the URI
in pieces under the assumption that a URI will be manipulated many times,
but serialized only once (or at least fewer times than it is manipulated).
This usage pattern is true in my suite, thus the usefulness of the class.
It also has some convenient URI manipulation methods that URI lacks.
* A DBI wrapper / A db-backed object base class - Yes, there are already a
bunch of these on CPAN...which means that, like me, each author wanted to do
something, it not better, then at least differently than any of his
predecessors. TMTOWTDI! :)
Moving on...
Each component depends on some or all of the components above it in the
list. So while some components (e.g., the HTML objects) would be useful in
isolation, actually submitting them to CPAN outside of this suite
hierarchy is a bit of a hassle (for the users and the developer) due to the
dependencies.
Let's look at two similar module suites already on CPAN: Mason and Maypole.
Mason is actually HTML::Mason, of course, reflecting (I'd imagine) its
creator's attempt to put it somewhere logical while not being too
frivolous with the name: it assembles chunks of HTML like a mason building
with bricks...or something.
But not long after its introduction, it quickly became just Mason to
developers. Furthermore, it also became clear that Mason is a lot more than
just a way to assembles blocks of HTML. It is a more like a complete system
for creating dynamic web sites and web applications. The HTML:: part of the
class name, although well intentioned, is now just noise.
Mason also includes things like its own method maker and various utility
functions that could technically exist outside of Mason, but don't.
Finally, there's the MasonX:: hierarchy which does away with the HTML::
baggage at last.
Maypole is a more recent example. It's an MVC web application framework
that avoids any pretense of being a HTML builder or any other sort of
thing trying to find a home in an existing HTML::, Net::, Web::, HTTP::, or
Apache:: namespace. It is essentially branded.
My suite is broader than either Mason or Maypole. In fact, it actually uses
and depends on Mason (and possibly also Template Toolkit) as part of its web
app framework.
It's my intention to release the entire suite as a branded entity much
like Mason, Maypole, or Bricolage, with a unique top-level namespace to be
determined later. (Obviously JCS:: will not do.)
I'm not sure if Maypole or Bricolage went through the module authors list,
but perhaps Mason did, and ended up under HTML:: as some sort of appeasement
to the class hierarchy Gods. If so, this was a mistake, and one I'd not
like to repeat.
I suspect the guardians of naming are already poo-pooing my intention to
create a new top-level namespace for myself, but the sky did not fall when
Maypole was introduced. Ditto for Alzabo, Rudesind, Bricolage, or even
MasonX.
Being nestled under Net:: or HTML:: or XML:: or whatever only makes sense
for a certain class of modules. At some point, when the level of
abstraction gets high enough, it's time to start assembling all of these
reasonably nested, generic pieces into more complex systems.
Those systems will, by definition, not fit nicely into any part of the
existing hierarchy. Trying to make them fit is disingenuous and leads to
more confusion, not less. Someone looking for HTML manipulation modules
will be quite surprised to run across a huge system like Mason sitting
alongside things like HTML::Parser, for example.
I think branding happens naturally for these suites simply because there
are only so many generic names for web application framework or
templating system. I also think it's clear by now that branded names like
AxKit, Mason, Maypole, or Bricolage are good fits for developer mindsets,
even if they don't fit into the One True Taxonomy of CPAN (as if there is
such a thing).
As you can see, I'm pretty much sold on the branded suite idea. In
addition
