On 11/5/04 8:00 PM, Mark Stosberg wrote:
> On Sat, Nov 06, 2004 at 12:29:23AM +0000, Smylers wrote:
>> Nonetheless I feel it would be worth doing this for anything completely
>> independent. It may be a little more hassle for you to release a few
>> separate distros rather than one -- but it would be a lot more hassle
>> for a potential user who just wants your DateTime or URI module to have
>> to grab the entire suite.
>>
>> More to the point they are unlikely to be noticed as part of a suite, so
>> your work won't get the attention and usage they deserve, and it's more
>> likely that somebody else will repeat them (only slightly different, and
>> incompatibly) elsewhere.
>
> I can second this. When I found Data::FormValidator, it was only
> distributed as part of a larger framework...I didn't want the larger
> framework, I just wanted the form validation. This module was not well
> known at the time. Since Data::FormValidator has been released on it's
> own, there's been a lot more activity around it.
There are a few things that make this difficult. The first is that any OO
"helper" module depends on the object base class and method maker. The
second is that the object base class and method maker are very simple, and
hardly worth distributing separately. The third is that even the functional
helper classes are very simple, and usually only exist so that I have a
single point of access for some functionality within my suite.
For example, the DateTime utils consist of two important functions:
parse_date() and format_date(). parse_date() parses the collection of date
formats that I find it useful to parse. It does so the old-fashioned way,
with a series of regexes in an elsif chain. It doesn't fit in at all with
the DateTime::Format:: family, nor is it meant to. The format_date()
function passes nearly everything through DateTime's strftime() method, but
it adds one or two special formats, and changes the meaning of a few.
The whole thing is a simple lib that just happens to accept and return
DateTime objects. It exists so that, if I ever want to parse or produce a
new kind of date within my modules, I can add code to one place.
Now I can't imagine anyone else finding this utility class very useful
unless they have exactly the same ideas as I do about what to parse and
produce. Nor would any user of the overall suite be forced to use this
class just because they use the suite. It's purely for internal purposes.
The URI class might be vaguely useful to "the outside world", but it relies
on the object base class and method maker. It also only handles a subset of
the URI formats that URI handles (again, because that's all I need to handle
internally).
In both cases, what would these things be called?
URI::Limited::ButEasyToManip? DateTime::Util::JohnsWhims? And then I'd
have to tear out the object base class and method maker too: Object::Simple
is probably already taken. The object base class is less than a page of
code anyway.
The method maker is a heavily simplified clone of Class::MethodMaker, which
I deemed too heavyweight for the amount of functionality I use in it. But
now my method maker exists only to hold all the weird kinds of methods that
I find myself using within the suite. How many of those would be useful to
others?
The only part that absolutely will be useful outside the suite is the HTML
objects module. But that depends on the object base class, the method
maker, the URI class, and the DateTime util functions. So now I'm right
back where I started, with everything in one big suite even if you just want
the HTML objects.
What I may consider is making the HTML objects and everything below them one
suite, and then the web app stuff above it into another suite that depends
on the HTML objects. But I'd still want them both under the branded
namespace. It'd be two distributions, but one brand. So if you just wanted
the HTML objects part, you could grab it while skipping the web app part.
If I tried to put the HTML objects suite elsewhere in a non-branded
namespace, then it'd seem odd that every web app object is a subclass of
HTML::Objects::Object or wherever the supposedly generic HTML objects module
suite lives.
If I absolutely had to split things out as much as possible into bite-sized
pieces (but all still branded), maybe it'd start to look like this (still
using JCS:: in the example)
JCS::Objects
Includes JCS::Object, JCS::Object::MethodMaker::*
JCS::DB::Objects
Requires: JCS::Objects
Includes: JCS::DB, JCS::DB::Object, JCS::Object::MethodMaker::DB::*
JCS::HTML::Objects
Requires: JCS::Objects
Includes: JCS::DateTime::Util, and JCS::URI
JCS::WebApp
Requires: JCS::HTML::Objects (which in turn requires JCS::Objects)
Includes: JCS::WebApp::*, JCS::WebSite::*, others (can't say what
exactly because this part is the furthest from completion)
Bundle::JCS
Includes: all of the above
Note that I stuck the db-related method makers in with JCS::DB::Objects.
That's the idea of my method maker: include only the methods that are useful
for your modules. The (very simple) "engine" is in JCS::Objects, but the
kinds of methods that can be made are determined by the "plug-ins" which may
depend on other modules.
In the example above, JCS::Object::MethodMaker::DB::* depends on JCS::DB, so
it makes sense to include it with JCS::DB::Objects. If it was included with
JCS::Objects, it'd either force a circular dependency or it couldn't be
tested at all.
You also might notice that no one is using JCS::DB::Objects. I plan to use
them for the "proof of concept" web app built using the suite. It will be a
test of both the DB stuff and the web app stuff. I'd probably then include
the "example app" as a separate module:
JCS::WebApp::Example
Requires: JCS::HTML::Objects, JCS::DB::Objects
Anyway, that's 3-5 things to download instead of just one. I'd much rather
just see a single, unified "JCS" distribution. It's not as if
search.cpan.org won't find the constituent modules if someone searches for
"HTML::Objects" or whatever. And I'm totally unconcerned with saving
bandwidth or disk space in this day and age. It's just a bunch of text
files, after all :)
But I suppose I could go the other way too, if that's the consensus. Also,
I think I actually meant to post this all to [EMAIL PROTECTED], but I jumped
the gun on my email client's auto-complete...
-John
