I am considering dropping the following for 3.1 release and need
feedback:
1. Bug Reports
This should be handled by LogBox and not the core. Plus using logbox
gives much more flexibility than current implementation
2. Plugins
The following plugins will be removed from the core and added to
ForgeBox:
- CFCViewer
- MethodInjector
- StringBuffer
- Zip
Scheduled drops for 3.5
- CF7 support
- XML Configuration support
- BeanFactory plugins to leverage wirebox completely
- Webservices Plugin and webservices aliases in configuration. This
can be done via wirebox or without it
- EnvironmentControl interceptor
- Autowire interceptor (wirebox adds support for all this, no longer
needed)
by no means am I an expert but i think the bug reports should provide handler/action level control. i.e. I should be able to specify bugReports or at least an override by handler/action so anything that offers this solution or close to it is a plus in my book!
Perhaps this already exists but I haven’t figured out how to do it.
Will you move the code into the plugins from the extensions for both the StringBuffer and Zip plugins? Since the code for these still exists in the core, does it make sense to remove them as they are just wrappers? Just a thought.
Scheduled drops for 3.5
CF7 support – Did I mention woot lately to this, cause just in case I didn’t WOOT.
XML Configuration support – That’s cool, will we switch the internal setup to use a cfc instead of the settings.xml it uses for the defaults now?
BeanFactory plugins to leverage wirebox completely – This one I think will be big for a lot of people as I think it is heavily used. Thoughts on keeping it another iteration and deprecating it now?
Webservices Plugin and webservices aliases in configuration. This
can be done via wirebox or without it - Sure
EnvironmentControl interceptor - Sure
Autowire interceptor (wirebox adds support for all this, no longer
needed) – Sure, it will remove confusion.
EnvironmentControl interceptor:
Does this mean, that the "environments" section in the settings
doesn't work any more up from 3.5? How will environments be handled
then?
Autowire interceptor (wirebox adds support for all this, no longer
needed):
In my CB-Apps, I'm using
<cfproperty name="userService" inject="model:admin.userService"
scope="instance" /> in my handlers/models to get access to my methods
in the models; calling for example <cfset userData =
instance.userService.getUserData() />.
How do I have to do this with wirebox? I've tried to do a 'wirebox =
{enabled=true};' in the config, and uncomment the autowire interceptor
in the config - doesn't work...
Environments will still be supported–and, you won’t loose any functionality.
The /config/ColdBox.cfc allows you to register environments based on a regex in the URL. ColdBox will then look for a function with the same name as your environment and execute it. You still can have per environment settings and you’ll gain so much more control because you can do anything via CFML rather than only applying settings.
For example:
function production() {
settings.cdn_path = “http://cdn.coolness.com”;
settings.allow_ssl = true;
}
function development() {
settings.cdn_path = “http://localhost/cdn/”;
settings.allow_ssl = true;
}
function workstation() {
settings.cdn_path = “http://localhost/cdn/”;
settings.allow_ssl = false;
I agree with Curt that the wrapper zip/string plugins may still hold value.
I however, am more inclined to take the pain upfront and stop supporting the BeanFactory. If someone is pushing beyond the 3.0 release into 3.1 I expect they have a desire to stay current with the framework and should adopt the practices we will be supporting going forward. Let’s just kill it off so we can all get past the hurdle of embracing WireBox–which I still need to do for Adobe TV :(.
The bean factory is probably the biggest thing on that list that will require a lot of changing for me. That being said, I think an extended find and replace should take care of most of it.
To be clear, the autowire DSL will continue to work as it does not, correct? The only thing that will change is when you interact directly with the bean factory plugin. I only do that in my services, which is where I create transient beans. Instead of injecting the bean factory, I’ll inject wirebox, and I’ll change from beanFactory.getModel(“modelName”) to wireBox.getInstance(“modelName”).
I guess my only other thought on this is that people are generally annoyed by incompatibilities between versions of a product just 'cause it’s a pain and they never understand why we couldn’t just keep it the way it was in the first place. I know we usually have good compatibility guides, but stuff like this makes it harder to find the correct docs since the docs start getting fragmented. That being said, I’m not sure if that’s a reason to make the changes slowly, or rip the band aid off and do them all at once. I’m thinking maybe the latter.
I think the compatibility arises if you do direct plugin.get model
calls instead of just get model calls. Maybe we can add a get model
alias to wirebox so it proxies to get instance to remain compatible.
Then in all reality you stay the same. Anyways I think removing the
bean factory is until 3.5 because cf7 needs to die first.
Thanks guys for great feedback. As for removing zip and string buffer
those will be removed from core too. However the zip will be removed
when cf7 dies as cfzip started with cf8
Am I correctly understanding that you are going to remove native support for ColdSpring and go WireBox only? (I’m guessing that I’m missing something.)
I know we usually have good compatibility guides, but stuff like this makes it harder to find the correct docs since the docs start getting fragmented. That being said, I’m not sure if that’s a reason to make the changes slowly, or rip the band aid off and do them all at once. I’m thinking maybe the latter.