What Basset is

Basset is the set of tools that I've been using internally for years and years and years and years. It has the advantage of a lot of maturity behind it, but the disadvantage of being exactly what I want it to be, which may not be what you want it to be. This is not a new, immature product. It's been around a long time and is pretty battle hardened. Good chunks of most modules even have really good test coverage. I think it's perfectly easy to use, but I'm biased. A former co-worker described it as cumbersome, but functional.

He also described it as "There's only one way to do it." My goal was to establish a set of tools and routines for myself to ensure solid consistency across my software. One of the gripes I have with CPAN is that everything is done differently to the point that tying disparate modules together can be a real pain in the ass. If your root object class uses inside out objects and your persistent layer uses arrayrefs and your logging module uses exceptions and your email rountines use error codes, then knitting it all together is a real nuisance.

With Basset, I was guaranteed that everything always plays together by the same set of defined rules. But I took it a step further - I made the rulebook user definable. So if I want to use error codes and you want to use exceptions, that's cool - flip a bit and it transparently swaps. If you want to use Class::DBI for your persistent layer and I want to use DBIx::Class, that's cool - flip a bit and it transparently swaps. Basset wants to ensure that you always play by the rules, and it suggests a rulebook, but doesn't care if you change the rules as you go along.

It's a generic application framework. Documentation is decent, though not outstanding, I don't think. There's a reasonably good tutorial up on my website at Basset Software to introduce you to things, but the introduction assumes that you use my rulebook and doesn't yet go into defining your own.

So you start off by subclassing off of Basset::Object. That gives you constructors and error handling and abstract factory capability and a few other things. You hang your class hierarchy off of here and you know that everything inside of it behaves the same way.

You don't like something? You change it. You can even change it inline and have your other subclasses care about it. The term I use is "injected inheritance", which may or may not be common. Apple calls it "isa swizzling" in their frameworks. For example,

Say when an error occurs, you also want to log it to a file. You simply subclass the root object and add on logging.

package My::Object;
our @ISA = qw(Basset::Object);

sub error {
    my $self = shift;
    
    #log interesting things
    
    return $self->SUPER::error(@_);
}
[download]

Or words to that effect. This works swimmingly, unless you download another object created by another user. They'll subclass directly from Basset::Object and bypass your logging. So you're back where you started - error handling works differently for different objects.

Basset gets around this by subclassing off of object types, not objects. So instead, you define My::Object as the root object type in your config file, and have your objects inherit from the root object type, not a particular class. Blamo! Your newly downloaded module gets your error handling, too.

There's more neat stuff like that throughout the framework, for my definition of "neat", of course.

What Basset isn't

Basset isn't just another persistence layer, though it has its own persistence class included. Sure, I could have just used Class::DBI or Tangram or Alzebo or whatever else, but I wrote my own (years ago) and refined it to my current liking. If you want to use it, that's great. If you don't and want to wrapper Class::DBI and drop that in instead, that's great. Again, Basset doesn't demand you follow its rules, it just demands you follow rules. But don't dismiss it because there's a persistence layer, it's just a bundled example of one that you can try.

Ditto on the templating system. Don't use it, I don't care. But I think they're both useful pieces of code, so I distributed them with the framework. I look at other app frameworks and templating engines and persistence layers for concepts and ideas, maybe someone else would like to look at mine. Share and share alike.

It's not a speed demon. It's fast. Really fast, I think. Especially compared to how it behaved years ago. But it's still a framework with some overhead and you can do things faster on your own if you do it directly, but the slowdown is manageable. Basset hounds are also a little slow, but manageable. Plus, the speed that they can produce in some instances can surprise you.

Basically, it's not just its individual parts, it's how the parts operate together that's the neat part.

So now what?

I feel like I'm throwing a party and nobody's coming. So how can I drum up support? While it's my project and I'm always going to be the gatekeeper, I really want to open it up to the world and get feedback and suggestions from everyone.

For example, Basset::Object::Persistent used to have an old, clunky, ugly (I say now) concept of attaching multiple tables to an object. The same former colleague I'd mentioned above made a big fuss about it and sang the praises of Class::DBI's has_a syntax. I looked it over, thought about it, decided he was right, and implemented something similar. Along the way, I added in transparent multi-table support so that one object can transparently map to multiple tables, not the 1-1 constraint you usually have.

And I never would have made that modification without his prodding. Now, he had to use it (we were using it at work), so he's a special case. But the rest of the world? You guys have a choice. Sure, I think it's neat, but I'm the proud father here. What, if anything, could get you guys interested in looking at it? I know that right now it's just Yet-Another-App-Framework. What'd be exciting? What would make you think, "Hrm, that might be worth checking out?"

I want to grow this thing into a community and hopefully make a lot of people's lives easier, but I haven't a clue how to do it.

Where should I start?