> On Wednesday 29 Oct 2008, Peter Boughton wrote: > > learning how to make wheels - for everything else you should pick an > > existing wheel and update as necessary, rather than rolling your own. > > There is another way: > http://www.joelonsoftware.com/articles/fog0000000007.html
Thanks for posting this Tom. I read this one not long ago actually... I suppose it's possible that some folks perceive me as having NIH syndrome since I've built so much between DataFaucet and the onTap framework. Although personally I feel what's in them is fairly unique despite the overlap with other frameworks. And part of the objective behind the onTap framework actually for a long time has been to allow for greater reuse of code between applications, even above and beyond what's possible with the previous frameworks for ColdFusion. You can of couse reuse code more easily between different applications on the same framework, for example with Fusebox you can have custom lexicons between different projects. With ColdBox and Mach-II there are plugins and filters that can be used between different projects. Where the onTap framework diverges from these other frameworks is that it encourages the reuse of aspects of the application that aren't as easily shared between apps with ColdBox, Mach-II or Fusebox. With these other frameworks you'll typically have a handful of tools that you'll take from one application to the next like client-side frameworks, an IoC framework (ColdSpring/LightWire), etc. But in each application you'll write most if not all of the controller layer from scratch (even if you do bring business objects from a previous project) and often you'll build a whole new database schema. That's a lot of duplicated effort for each new project. By comparison DataFaucet and the onTap framework encourages the reuse of an entire controller layer and an entire database schema from one application to the next. (And really you could easily swap out Steve Bryant's DataMgr which is much more compact instead of DataFaucet and get the same effect.) Generally speaking I'm advocating the same kind of distinction Joel Spolsky makes at the end of that blog. If its part of your core business, write it yourself, but if it's "one off" as is usually the case with things like forums or contact systems, there should be an easier way to integrate someone else's existing app into your client's project and tweak it in a way that maintains the integrity of the original to support future upgrades. Some of us are doing that already with what's called "single sign on" (SSO). It works, but it's problematic - each application (forum, contacts, etc) has its own permissioning system, so you have to write custom code to maintain the configuration across them. What I'm talking about is the next step beyond SSO and that's Service Oriented Architecture (SOA). Designing the applications so that instead of each application duplicating the effort involved in creating its own member management and its own permission system, they can all take advantage of a pre-installed member management and permissioning "service". And just as they take advantage of application security as a service, these sub-applications can also exploit each other to create powerful integration between applications. Adobe does this with their products already - for example, there's integration for Flash and PDF both built-in to ColdFusion. But right now that's not the case within the broader ColdFusion community. All our apps are stand-alone and that means they all duplicate a lot of effort. To put it another way, why did FuseTalk and Mango Blog and BlogCFC and Galleon all create their own member management and security APIs? Does it make sense for every application to reinvent those things? Imagine for a moment if these were non-networked desktop applications instead. Imagine that it's a different kind of program like say Photoshop or GIMP that runs on the desktop in Windows or Mac or whatever your preferred flavor of Linux is. The job of the security framework would be to decide what files the current user is allowed to view and edit. Would it still make sense for each of them to spend time writing code to reinvent the idea of a "user" and "permissions" when the operating system already has a robust user/permission service available? Personally I think it makes sense for desktop applications to reuse the features of the operating system, and similarly I think it makes sense for CF applications to reuse each other. I'd like to see that kind of collaborative reuse become a bigger part of ColdFusion frameworks in general. My understanding is that SOS and COOP have similar goals along with the onTap framework, so if you're interested in these ideas check out the onTap framework but also check out SOS and COOP. You can find more on them here: http://sos.riaforge.org and http://coop.riaforge.org There's a decent high-level view of the onTap framework goals on the wiki here: http://ontap.wikispaces.com/Project+Goals -- s. isaac dealey ^ new epoch isn't it time for a change? ph: 781.769.0723 http://onTap.riaforge.org/blog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:314577 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
