New ColdObject MVC Framework For ColdFusion

Ouch, talk about DOA. "However, the popular frameworks (Marc II, Fusebox, Coldbox, etc.) that are currently being used do not support the CF rapid development concept, all CF features or work well when developing simple or complex online applications." The document goes on to create objects with each session in onSessionStart... And then does a structClear against the sessionScope, which is what the cf docs say NEVER to do. I couldn't read any further...

> I would even say the same thing regardless > of the framework in question. Very wise words!

I also agree with the first comment. Look at other MVC frameworks. FW/1 is a good one.

I'm afraid I must agree. Make sure to evaluate your needs very carefully before making any decisions. I would even say the same thing regardless of the framework in question.

Totally agree with the first comment. A real long hard look...

Is this a joke? That has to be one of the worst frameworks I've ever seen, and the fact that someone is actually using it is even scarier. The framework is NOT MVC! Throwing all your code into one of a few CFCs is not MVC. This is another one of those cases where someone didn't understand a framework and decided to write their own because the others were "too complicated." Very typical of way too many CF developers.

I'd give this one a long hard look, and be sure to do comparisons to other MVC frameworks, before using.

We created the ColdObject Framework with several things in mind. The purpose of any framework is to improve the efficiency of creating software. A sound framework should be robust and improve developers’ productivity, plus improve the quality and reliability of the software. The ColdObject Framework improves developers’ productivity by allowing them to focus on the requirements of their application instead of spending time on application infrastructure. Many people equate the term “software framework” with an object-oriented software library, or set of libraries, intended for reuse. Therefore, the ColdObject Framework is a means, not an end. Developers can select to use cfm files or CF components. However, there is an important difference between a framework and a library –– that difference is called “inversion of control.” Any framework should give developers the ability to implement objects and methods that are custom to their application and all processes are instantiated and invoked by the framework. The main point here is that a framework defines the flow of control for the application. The MVC architecture concept outlines three areas of a software application and they are Model, View and Controller, respectively. The ColdObject Framework follows the MVC architecture in the following manner: Model = DataAccessObject.cfc View = Interface.cfc Controller = Index.cfm I would be happy to speak with other software developers about the ColdObject framework approach. I may be reached at 443-567-8747 or rbolling@bollingtechnology.net.

I frequently post items that may be of interest to the ColdFusion community. When I post recommendations, be they for articles or services or products, then I make that clear. When I post items that I bump into or that cross my e-mail, then I post concise posts without any opinion implied. That's what I did here, and noted the creators claims, not my own. I posted it so that others, especially those more competent in this space could comment, and they've been doing just that. As for the recommendations by Joe and others that a long hard look is needed before using, I agree, and I've repeatedly said that of every framework, for many many years, since early Fusebox days. --- Ben

I would urge readers to recognize that Ben's post isn't worded as an endorsement of this framework. In fact, if Ben would actually look at the code in question, I'm guessing he would either pull this post or update it with a strong disclaimer. It looks like a high school computer class project. If I were interviewing for a job, and this was what their site was built on, I'd remove my name from consideration. This would be an unbelievable mess to try to maintain for even the smallest sites.

I am extremely disappointed with the non-substance negative feedback that has been posted on Ben’s blog regarding the ColdObject Framework. My intent was to share my working framework approach with other ColdFusion developers and stimulate sound technical dialogs not junior high school banter. I have opened the door for constructive dialog and if anyone would like to communicate please feel free.

I always wonder if people developing these frameworks have anything useful to do.

Raynard, since you seem open to constructive feedback, here are some thoughts. I figured I'd share them here rather than in a direct email so that people could see that the points have been shared and how you may respond to them. In fact, that will lead to a point I make about your chance to improve such dialogue. I think you would help your cause at least a bit with a few things: - fix the typo for "marc II" (it's mach II). That's starting off on the wrong foot, given especially that the most likely first viewers will be those already invested in CF frameworks and interested in comparing. - Along the same lines, it would make sense to tone down the somewhat aggressive tone against other frameworks in that sentence. Even if you may feel justified, consider again that the earliest observations of the page (and about the f/w) will come from people who will be especially sensitive to such an assertion - you really should switch from using a PDF to describe things to using a web page (for reason's I'll get to in a moment) - you should consider creating place about the framework on your site that people could point to that (versus just the PDF or your front page with the downloads). Just doesn't convey as much seriousness the way it's projected right now - While it's admirable for you to offer your email and phone number here, you will really want to offer that there. - Indeed, it might be better still to facilitate an observable feedback mechanism there (blog with comments, forum, mailing list, whatever) so that people can see the concerns being raised and addressed - All this would help shape your doc (even if you would only ever keep as the few-page overview you have in the PDF). But by making it a web page instead, at least it could evolve, whereas a PDF is stagnant, and could get shared with "old info" - indeed, if you may be interested in open sourcing the project, you could list it on a site that offers them (like riaforge, sourceforge, google code, etc) which would also provide those resources for interaction Hope that's helpful. (I've done no further review of things and likely won't--just not an area of focus for me right now. I'm just offering this as objective observations from what's been said here and elsewhere.)

Charlie, thank you for your helpful recommendations!