Mail Bag : Framework Community Picking Up Steam

I've been answering a steadily increasing number of emails regarding both DataFaucet and the onTap framework in recent weeks and I wanted to share a few of those conversations here. So with permission, here are a few of those comments.

John Whish, the manager of the Devon CFUG says:

Hi Ike,

This VPA thing has really got my attention. Can I run a scenario past you to see if it will solve my problem?

I have built a SaaS application that allows users to enter timesheets, it then generates invoices. What is happening is that new clients are coming on board who don't use the same rates model. For example most users charge a flate rate on a Sunday per hour, but some want a day rate and a night rate. Building a one-size-fits-all solution is possible but very complicated and hard to use.

I can see that you could have different ratemodel objects that you could simply drop in, depending on what the client wants, so that if a new client comes in who charges in 3 minute periods, I can just create a new ratemodel with the same methods and it will just work. Is that what onTap lets you do?

The short answer is yes.

Of course, there's always a longer answer. :)

Indeed, this is the kind of problem I'd seen at numerous companies over the years and the sort of thing that inspired much of what's gone into the onTap framework. Pricing models seem to be a particularly common source for these kinds of issues. John's right that the notion of a "virtual private application" or VPA specifically was inspired with the intent of addressing these sorts of problems. While there's never a silver bullet, we can often do better than what we've got by applying techniques like our VPA and honestly I'd like to see others addressing these issues as well. Although I think the onTap framwork solutions are pretty elegant, I think the community as a whole would benefit quite a lot from having more creative problem solving in this space.

I offered a more detailed technical answer to John in private email which he was pretty happy with.

Next, Gabe Roffman writes:

I really love what I've seen of the onTap framework and have been reading some of your blog and I seem to strongly agree with everything I've read of yours so far. You may recognize my name as one of the original creators of Fusebox. I've cringed over the years as I've seen the framework become more bloated and complicated and why does everyone love xml configuration? onTap seems an extremely reasonable framework.

I'm flattered of course. :) Although for some a comment like this may produce an image of people just being bitter, I don't think that's what's going on here at all. I think all frameworks ultimately start because someone or some group of people are dissatisfied with the available solutions to the problems they face. Heck I don't think Fusebox would have come about in the first place if it weren't for general dissatisfaction with what they call "cowboy coding". You can see that in articles about the history of Fusebox like this one on Peachpit.

In spite of their similarities each of the popular frameworks for ColdFusion addresses different issues because the authors and the communities involved in them are wanting solutions to different sets of problems. In the case of the onTap framework the VPA structure John Whish mentioned is one of the specific reasons for its development.

For gabriel and myself we simply don't feel as productive when we're working with the kind of XML configuration files found in previous versions of Mach-II or Fusebox 4, although I have noticed that there has been significant progress recently even with Mach-II to make those XML files less verbose.

And we're not the only ones who prefer less XML as shown by the CoC approach of ColdBox and FuseBox 5.5. Although I didn't know it had a name, I wanted CoC back when Fusebox 4 was first released and made some noises about that which were ignored at the time. The "implicit circuits" in the latest version of Fusebox are actually pretty similar to what I'd suggested when 4 was released. It just took a little while for CoC to catch on.

Gabe Continues:

It always looked interesting to me. The reason I never went further than a look was because it seemingly had no community support. Since you are the sole developer, it was unclear how long anyone would continue developing it. That's always a risk.

Anyway, good job on the framework. Looks very well thought out. Just like something I would do. :)

That's a legitimate concern that a lot of people have. This isn't the first time I've heard it and I suspect it affects a lot of new projects. The onTap framework is hardly new anymore, although the latest version is a significant improvement. It's been around since 2003.

So if we're 5 years old, what's the hold up? Frankly it was me. I just didn't know that until recently. So now that I know that I just wasn't networking enough, I'm focusing most of my efforts right now on networking and improving community involvement.

I've put the framework back on its own domain, I've added a wiki and created a Google group for discussion. I've added livedocs style comments on the official framework site and published a survey to help get some feedback on what people are looking for in a framework. I'm still wanting more participation in that survey although as of right now it seems the biggest issue has been simply that people are unaware that the framework exists. I'm also giving presentations for user groups as much as possible and actively seeking an evangelist and a technical writer to help shore up my skills in those areas.

The reality is that I've always wanted the framework to be community driven. So now we're 5 years old, we're growing strong and we're even receiving donations! So now's a great time to get involved and help us make this project awesome! :)

And then Gabe offered a couple of comments specifically about DataFaucet:

Looking at DataFaucet and...

Finally a ORM that supports multiple datasources!

It's very exciting that my foreign key constraints are recognized by the ORM so that they are actually useful.

I responded to this with a comment about not understanding why people don't use foreign key constraints. They're uber-easy to create and they make your applications fundamentally better. To which Gabe replied:

I'm still using SQL Server 2000 and I like the diagramming features that allow you to create those relationships. I think if people understood that they can create a data diagram pretty well in Enterprise Manager and that by making the links in the diagram, that it will carry over to datafaucet, people would be more interested in using it.

I actually like using DataFaucet's DDL tools to define and create my databases and that way I can just specify references="table.column" in the column tag and viola! You have a foreign key constraint. However WISYWIGs can be nice too! :) I may try and make a video to show how these are done.

Maybe these last couple of comments should be on the DataFaucet blog instead. :P