Currently we are planing to use a framework for our projects at the university and I stumbled upon on coldbox, after several dicussion we decided to go with coldbox lite - because of its lite footprint - but only if we can add interceptors and testing ability to coldbox lite.
As per wiki extending coldbox lite should be no problem.
So what is easier!
using coldbox lite and adding interceptors (SES, Security) and Testing
useing coldbox and stripping of not needed stuff
Main focus is that the framework should have very lite footprint. Glad to hear your suggestions.
Thanks for working with us. Here are my suggestions.
interceptors
Interceptors are one of the biggest features of the ColdBox Platform as it allows you to not only intercept requests at specific points in the application, but also to apply event-driven features to your application. This can allow you to broadcast internal events where listeners can be working in a very decoupled approach. However, this machinery is not part of ColdBox LITE but of the ColdBox Platform. Technically you could leverage our event managers in the core and apply them to ColdBox LITE but only to allow you to register and announce events. Meaning you will have to announce the interception points yourself.
Testing
This can be done wether you are lite or not. MockBox works as well. So I don’t foresee where you can’t use this. If you hit some bottlenecks I am sure we can help out.
SES
The SES interceptor in ColdBox takes care of all the major RESTful features of the framework. Therefore it cannot be applied easily to ColdBox LITE as it requires dependency on the ColdBox Platform request context. Therefore, if you really need RESTful capabilities you will need to leverage ColdBox Platform.
One misconception is that ColdBox Platform has a heavy footprint. It actually requires about 15K of RAM. Just because the platform contains more files than LITE does not necessarily mean they are loaded. Actually, ColdBox auto-assembles itself at runtime depending on your configuration file. It was built for high availability mission critical applications, so it is tuned to perform and respond. ColdBox LITE is just the MVC subset in which actually the new ColdBox 4 core will be built around.
Honestly, if it was me I would just use regular Coldbox. It still has a very small footprint and most things like plugins aren’t even created unless you use them. I see more value in the additional features of the full platform in comparison to the time LITE would shave. I would be surprised if performance in your app was so tight you would notice a significant difference between full ColdBox and LITE.
Why not do do some testing? Create some full working pages that do all the stuff your app needs to do. You’ll probably find framework processing to be a negligible amount of processing time in comparison to your app’s database calls and logic. Besides, if you are concerned about performance you’ll want to use features such as view and event caching which are only in the full platform
It’s more like that the DevTeam at the University focusing always on longterm, doesn’t want to manage a Codebase about 5.5 Mb in case - don’t want to be rude - the framework should not be continued. And if we decide to use a framework we need to be sure.
Any chance that i can use original Coldbox and strip off unneeded parts and have a smaller codebase.
I’m a little confused. Are you short of hard drive space on your servers? You can strip out plugins, appenders, cache providers and such that you don’t need, but honestly to me that’s like throwing out the spare tire on your car so you have 20 pounds less car to maintain
I’d say you’re over-optimizing right now. The framework only loads that it needs, and you don’t maintain it-- we do. You just upgrade the coldbox/system folder when new versions come out. It’s true ColdBox has a few more lines of code than other frameworks, but it also has unparalleled flexibility and flexibility. Make sure you consider the long-term benifit of the ColdBox Platform in your technology choice.
I can’t promise you the future, but I will point out that ColdBox is the only professionally-supported CFML MVC platform (that I know of). It is backed by Ortus Solutions who provides support, training, books, and custom development. We also have an internal roadmap for the next year and a half right now of new features and tools we want to build. The rest of the CF frameworks are all maintained only by volunteer community members and have little new activity. I’d say ColdBox has the least likelihood of disappearing out of any of the existing CFML frameworks.
We are working on a roadmap document at the moment that we will be publishing soon. However, for tickets you can check out our tracker where all these things will be posted:
@everybody: Is there a video with overview of the coldbox platform itself - showing the possibilties, features and the philosophy behind it. Like if you would go to a company and convince a buch of developers by showing them how the platform could ease their work. I would like to present the teammembers this overview and try to convince why we should use coldbox as framework.
I want to really convince the teammembers therefore i need help!!
Regarding videos, we also have a bunch of webinars from our ColdBox Developer Weeks as well as our ColdBox Connection meetings. These cover all sorts of ColdBox-related topics:
I think that the OP is concerned with maintaining not only his team’s app(s) but also the framework itself in the event that Luis and the good people here - sometime in the future - are not around to support it any longer (e.g. what just happened with Mach II).
A smaller footprint framework would mean less of a code base that his team would need to “manage” should Team Coldbox sunset the framework.
Which is always the first thing that gets asked by management… Who develops and supports it, if the developer of said framework was too for any reason not be able to maintain it, becomes an issue to anyone who wishes to adopt it. Especially with management…
That’s exactly the Issue, one teammember used to work with a framework which after all has been discontinued.
Finally we decided after a hard discussion to use Coldbox Platform for two projects at our University and I’m glad that we make this step to get a bit more conventions on developing.
But on some level, the risk is the same (if not quite a bit greater) if a framework isn’t chosen and the “framework” is developed in house (which is ultimately what will result, regardless of how robust, extensible, or manageable that internal solution might be). After all, if key internal resources leave, the same challenges exist.
With a third-party framework, you (hopefully) at least have the benefit of documentation, support, community involvement, etc. And even if it gets discontinued, your adoption of the framework is hopefully solid enough to continue to use for the near term while looking for alternatives in the longterm.
Of course, “longterm” with software is a very illusory concept, right?. Regardless of the future growth of any particular framework, the sites that you’ve implemented on it themselves may potentially need the ol’ rebuild anyway, depending on how they grow, the requirements for your business, etc. At that conceivably inevitable point in the lifecycle of an application, you might–because of changes in management, personnel, or other factors–want to move to an entirely different framework (or language, or both) anyway.
Here are some points from us, to give a state of the BoxUnion:
ColdBox is now entering its 8th year of maturity (believe it or not), we did our first Open Beta in 2006. It has been a professional open source project for that long as well and it is used by thousands of companies and developers world wide. From companies like NASA, JPL, StepStone, IDG, Army, Air Force, State Departments, Adobe, etc. We have not only invested quite a lot on our platform but are building a huge ecosystem from ContentBox Modular CMS, to ForgeBox community, to now commercial product additions. We have been offering professional support programs and mentorship programs for over 4 years now and have a services stack defined as well. We have a very defined model of where we want to take ColdBox not only as an open source project, but also as a suite of services and additions to support the community not only for the next year but 5-10 years.
You will most definitely expect minor or patch releases in 2-4 month intervals with major releases being developed every 2 years. We have over 5 professional courses in our catalog and several more in development.
This are some pointers of what we have been doing and where we want to take ColdBox. Hopefully this can give you an insight of where we want to go. We will also be releasing our CB4 roadmap soon.
