Questions about using coldbox features for a large existing project

I see a lot of positive feedback about coldbox, and especially notice Brad Wood is very active with the Railo group. It’s clear to me that this project seems ahead of the rest on documentation and unit testing, which are fundamental to have on a larger application if you want to do team-focused development. So I’m curious if I should try to integrate / extend coldbox with my existing app or just continue working on my own approach to the same goals as your project.

Can coldbox be used when ACF/Railo sandbox have all options disabled? (java, cfexecute, cfobject) I noticed there are many createobject(“java”) calls, and I don’t know how many of those are required for basic coldbox features. Currently, my app doesn’t require java for its features. I’m working to make cfexecute optional.

Can you migrate to coldbox incrementally and use only some features like forms/validation initially?

Is it typically difficult to migrate to the next version of coldbox for an existing application implementing it? I wouldn’t want to find myself stuck on 3.5 for years after coldbox 4.0 being released for example. I like to work with bleeding edge versions usually. I assume this will mostly depend on how many unit tests I implement related to your public API.

If you had a custom CMS application with over 100,000 lines of CFML, 200+ tables, and a 50,000+ lines of javascript that doesn’t have unit tests or detailed documentation, do you think it would be better to start writing tests / documentation for it without using coldbox or migrate it to coldbox to save time on testing and documentation?

My app will be released as open source eventually, and I want to be have a structure that inspires others to collaborate with me.

I’m curious if there is a high level of demand and interest in coldbox that justifies the extra work to make it a successful open source project. Most of the work I do lately is focused on thinking about open source / team collaboration rather then other business goals. I’m hoping the community will get excited about the projects I release when they become more visible and relevant to them and that it won’t just be a burden to manage the community questions, bug reports, and such. Ideally, some portion of development will become cheaper from having the exposure an open source project can gain. Have you found this to be the case with coldbox?

If you had a custom CMS application with over 100,000 lines of CFML, 200+ tables, and a 50,000+ lines of javascript that doesn’t have unit tests or detailed documentation, do you think it would be better to start writing tests / documentation for it without using coldbox or migrate it to coldbox to save time on testing and documentation?

For what it’s worth, this is exactly the situation I’m in right now and one of the reasons I chose to do a full re-arch on a client legacy app (that has been spaghetti-coded a piece at a time for nearly 15 years) in to ColdBox. I first checked CB out when it started and elected to use ModelGlue, which I still maintain several apps on. Speaking only from a thousand lines of code or so, I’m really impressed by how elegant this framework adapts to my own coding conventions. It’s been fun to learn. You’ll probably cut those 100,000 lines of code down by 70% or more with good MVC practices and leveraging the ORM.

I don’t know about the lifecycle and backward compatibility too much but, having used frameworks that break backward compatibility with nearly every release, as long as you update with every release, you can usually find/replace 95% of what needs to be updated. Writing good unit tests also takes care of the ‘scary-factor’ in deploying updates. If you get lazy and procrastinate on porting to a new release, though, woes abound.

Can coldbox be used when ACF/Railo sandbox have all options disabled? (java, cfexecute, cfobject) I noticed there are many createobject(“java”) calls, and I don’t know how many of those are required for basic coldbox features. Currently, my app doesn’t require java for its features. I’m working to make cfexecute optional.

In response to this question, if cfobject is disabled, you won’t be able to use any modern CF applications. ColdBox uses java objects extensively. If your host insists on disabling these, I would suggest a different host.

Hi and Welcome Bruce,

Sorry it took me a while to respond, been a crazy week. Here are some thoughts for you!

I see a lot of positive feedback about coldbox, and especially notice Brad Wood is very active with the Railo group. It’s clear to me that this project seems ahead of the rest on documentation and unit testing, which are fundamental to have on a larger application if you want to do team-focused development. So I’m curious if I should try to integrate / extend coldbox with my existing app or just continue working on my own approach to the same goals as your project.

Thank you, we really try to push the envelope and going on more than 7 years now with our projects and products

Can coldbox be used when ACF/Railo sandbox have all options disabled? (java, cfexecute, cfobject) I noticed there are many createobject(“java”) calls, and I don’t know how many of those are required for basic coldbox features. Currently, my app doesn’t require java for its features. I’m working to make cfexecute optional.

ColdBox requires objects and some internal java native objects. So it defeinitely requires the ability to create CFC’s and Java Objects. I don’t think this should be a problem nowadays when if you can’t instantiate a CFC then it is really old code. Unless a shared provider does not allow this.

Can you migrate to coldbox incrementally and use only some features like forms/validation initially?

Yes. ColdBox is built modularly internally. You can leverage just MVC and then keep adding ingredients to your recipe. Only the things you define in your config area loaded.

Is it typically difficult to migrate to the next version of coldbox for an existing application implementing it? I wouldn’t want to find myself stuck on 3.5 for years after coldbox 4.0 being released for example. I like to work with bleeding edge versions usually. I assume this will mostly depend on how many unit tests I implement related to your public API.

We try to make everything seemless from version to version. There are compatibility guides we produce with step by step guides on how to upgrade and if there are any compatibilty issues. We have not seen huge issues in this past 7 years with tons of clients and installations.

If you had a custom CMS application with over 100,000 lines of CFML, 200+ tables, and a 50,000+ lines of javascript that doesn’t have unit tests or detailed documentation, do you think it would be better to start writing tests / documentation for it without using coldbox or migrate it to coldbox to save time on testing and documentation?

I would probably start from scratch since most likely that application is not Object Oriented or in any type of MVC framework. It would be like putting a square peg in a round hole. Sometimes you just have to reinvent your software to push forward. We just launched TestBox alpha as well, so we have you covered in terms of testing and bdd.

My app will be released as open source eventually, and I want to be have a structure that inspires others to collaborate with me.

I’m curious if there is a high level of demand and interest in coldbox that justifies the extra work to make it a successful open source project. Most of the work I do lately is focused on thinking about open source / team collaboration rather then other business goals. I’m hoping the community will get excited about the projects I release when they become more visible and relevant to them and that it won’t just be a burden to manage the community questions, bug reports, and such. Ideally, some portion of development will become cheaper from having the exposure an open source project can gain. Have you found this to be the case with coldbox?

We have a great community Bruce. We have our own repository as well ForgeBox (www.coldbox.org/forgebox) which will be getting a facelift soon and much more features. We are planning some great things for ColdBox 4 that will allow users to share their code much easly and even track dependencies in their projects via a nice CLI. So we are moving forward and we need good people aboard :slight_smile: So can’t wait to see what you bring to the table!

Bruce, I don’t know your familiarity with the ColdBox platform (and it’s host of *Box libraries it comes with). Each of these libraries can be used as stand-alone or as part of the MVC component.

  • LogBox

  • MockBox

  • WireBox

  • CacheBox

  • TestBox

  • ColdBox MVC (Comes with everything above)
    Furthermore, our libraries and MVC platform provide a very high level of extensibility.

  • Add custom appenders to logbox

  • Define custom builders, and legacy IOC containers for WireBox

  • Define AOP aspects and listeners for WireBox

  • Add custom cache providers for CacheBox

  • Add custom runners and reporters for TestBox
    Also, our products are made with modularity in mind so you can share interchangeable code easily with any ColdBox application:

  • Interceptors that modify/extend parts of the core application/session/request lifecycle

  • Plugins that provide drop-in libraries of your creation

  • Modules which are a self-contained “slice of MVC” that you literally drop in your modules folder and it registers it’s own routes, layouts, handlers, views, plugins, interceptors, etc into the main app
    And finally we have our full-fledged CMS called ContentBox which is an amazing collection of ColdBox modules you can drop into any ColdBox application. ContentBox developers can easily share the following:

  • Site/Blog themes

  • CMS Modules

  • CMS Widgets
    And everything in the last three bulleted lists are available on ForgeBox http://www.coldbox.org/forgeBox and installable at the click of a button using our ForgeBox module, ContentBox’s admin, or our CF Builder extension.

You won’t find another group in the CF world with this much traction when it comes to community open source vision, extensibility, and making it as easy as possible to share your libraries with the world. If you have questions about how any of this works, please feel to ask more questions. In the mean time, I don’t know how familiar you are with the *Box family, so here are some short PDF ref cards that will get you started with ColdBox, ColdBox LITE, CacheBox, and WireBox:
http://wiki.coldbox.org/wiki/Dashboard.cfm#PDF_Ref_Cards
We have ref cards in the works for many other aspects of Box-world, but this is what’s done thus far :slight_smile:

You asked about backward compatibility. Here is a link to our compatibility guides so you can see the care we take to document new features and any significant changes.
http://wiki.coldbox.org/wiki/Dashboard.cfm#Compatibility_Guides
http://wiki.coldbox.org/wiki/Dashboard.cfm#What’s_New_.3F

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thank you so much for the feedback. I care so much about my app. I can tell you guys care about yours. You are doing the best work for the cfml. Keep it up!