ColdObject is a new MVC framework for ColdFusion development. Its creator, Bolling Technology, claims that this MVC implementation manages to strike a better balance between structure and rapid development. ColdObject is already in use at U.S. Bureau of Economic Analysis (BEA) and is currently being evaluated by U.S. General Services Administration (GSA).
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.
> of the framework in question.
Very wise words!
"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...
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.
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
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 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.)