[testbox/coldbox 3.8.1] getPlugin not returning new instance

Communities ColdBox HMVC
#1

I have a plugin, and inside the init it sets the time and a UUID.

Inside a TestCase, I do this:

var Plugin1 = getController().getPlugin(‘PluginName’,true,true);
writedump(Plugin1.InitId);
writedump(Plugin1.InitTime);
writedump(Now());

writeOutput(’

’);
sleep(5000);

var Plugin2 = getController().getPlugin(‘PluginName’,true,true);
writedump(Plugin2.InitId);
writedump(Plugin2.InitTime);
writedump(Now());

Despite the third argument being true, it is returning the exact same instance.

I tested the code inside a Coldbox view and it does the same thing - returns the same instance twice instead of a new instance.

Am I misunderstanding how getPlugin is supposed to work, or is this a bug?

#2

Ok, so digging into the Coldbox source, here’s the getPlugin function:

if ( arguments.newInstance ){ return services.pluginService.new(arguments.plugin,arguments.customPlugin,arguments.module,arguments.init); } return services.pluginService.get(arguments.plugin,arguments.customPlugin,arguments.module,arguments.init);

And here’s the get from pluginService:

return new(argumentCollection=arguments);

i.e. there is ZERO difference between passing newInstance true or false - the exact same arguments are passed in.

That definitely smells like a bug to me.

For now I can workaround it by specifying scope=“noscope” as a component attribute for the plugin, but that of course means I always get a new instance, even when that isn’t necessary, so will slow things down.

#3

+1 for looking at source to find your answer :slight_smile:

Originally, plugins took care of their own object creation. Around ColdBox 3 or so, we switched the plugin service over to use WireBox behind the scenes. I vaguely even remember “new” possibly being deprecated though there’s nothing in the comments saying that was on purpose.

In ColdBox 4, we’ll be getting rid of plugins (by that name) and just treating them as models so you’ll just be asking Wirebox for them just like any other service, bean, library, etc.

So, with that being said we’re unlikely to roll out any changes to getPlugin() since we’re about to deprecate it. What I would actually recommend is seeing if you can just switch over to using WireBox now to get your CFCs. It’s basically the same thing (which is why we’re simplifying the whole process). The only real catch is if you are using any of the frameworksupertype methods or the auto-injected references to logbox, cachebox, wirebox, etc you’ll want to still extend coldbox.system.Plugin or just start auto-wiring those bits yourself.

Now, WireBox doesn’t have any concept of overriding a mapping persistence at the time you request it (which is most likely why that functionality got lost). In WireBox you create a mapping with the persistence properties you want and then just request it. So, if you want to be able to request a mapping that is a singleton as well as a mapping that is a transient (even if they point to the same CFC), you create two mappings in your binder config (WireBox.cfc) and request the appropriate one.

map("longLived).to(“path.to.cfc”).asSingleton();
map("shortLived).to(“path.to.cfc”).into(this.SCOPES.NOSCOPE);

And then do getInstance(“longLived”) and getInstance(“shortLived”).

Also, keep in mind that the DSL in your binder config overrides the annotations in your actual CFC. That means you can simplify your life and put the default persistence settings in the CFC’s annotations and only create a mapping manually for the override.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

#4

brad, what will happen to my plugins in v4?

#5

They will be treated just like regular models. That’s basically all they are now anyway-- just simple CFCs that don’t have to implement any interface or extend any base class. We’re just removing the formality of them having a special name. Instead of doing getPlugn(“foobar”) you’ll do getModel(“foobar”).

You can read more about it here in the PDF roadmap:

http://blog.coldbox.org/blog/coldbox-4-roadmap-released

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

#6

it sounds weird to group together plugins with my model only in that when i look at code, i wont know that whats being fetched is a plugin.

i could add the word ‘plugin’ to the name to explain the object.

#7

I’d say that’s mostly because you’re just used to calling them plugins. Quite frankly, they don’t “plug in” to anything. They’re just generic CFCs with methods that you can call anywhere. The entire “plugin” convention was created back before ColdBox had WireBox and the models convention. If those would have existed back then I don’t think we ever would have created the “plugin” name. I would say most plugins would actually fall in the category of services or utilities.

What you call them and how you organize them in your app will still be up to you. In fact, you could totally leave them in a folder called “plugins” if you wanted to. Like Pete already discovered, all the getPlugin() method has been doing for years is just turning around and calling wirebox.getInstance(). We’re just going to remove that last bit of abstraction.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

#8

Or widgets?

#9

to me, a persistent model is a row of data in a table.

services help crud a persistent model object or get objects like it. or do both, but with some app logic.

a utility is like an application helper. a grouping of like or unlike methods.

a plugin is a decoupled, blackbox object that can do things like render a html widget, be some type of factory to input/output whatever, or an extension of an app. like wordpress and its multitude of plugins.

i could see a plugin like a module but w/o the complexity of its own mvc.

#10

FYI, In comparison,

What Grails calls a plugin is what ColdBox calls a module, Grails also has another area outside the model for what ColdBox calls plugins which is the Sources (src) folder. I wouldn’t mind if ColdBox followed the same naming for the new plugins area instead of within the model folder. I too like to have a place outside model to create functional classes, like pdf template population libraries for example (currently in plugins) that really don’t make sense in the model or as a full blown module.

just a thought… :slight_smile:

#11

Phill,

Yes, our plugins are nothing but objects nowadays managed by WireBox. In the 1.0 days, I had to build everything from scratch. For 4.0 we will push WireBox to the forefront more.

Thus, modules will be getting more of a spotlight, but also you can leverage getInstance() instead of getPlugin() to retrieve any CFC ANYWHERE in your server. So you are not restricted of where the CFC lives. WireBox will be smart enough to build it and wire it for you. So basically instead of this:

getPlugin() → getInstance()

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

#12

If internally this is not a change as the system works this way anyway, does a plugin actually have to be called a plugin or can it keep that definition. Then what happens to widgets who are all in purpose an extension of plugins?

I don’t think anyone cares under the hood how it works, the damage is what we see and perceive. I agree a plugin now being called a model is going to get confusing.

Why not just keep it as a plugin and it is short for a Plugin Model?

signature0.jpg

#13

The model folder in ColdBox is just the default convention where WireBox will look to find any CFC of yours regardless of the type or function of said CFC. Don’t get too hung up on the name. We could have just as easily called the folder “CFC” or “lib” (like Java), or “objectOrientedStuffHere”. What you do inside that folder is up to you. For instance:

/model
/model/beans
/model/services
/model/DAOs
/model/plugins

In fact, you don’t even have to use the model folder at all! All the model folder is, is the default scan location for WireBox. You can add additional scan locations, or just map your CFCs directly in the binder config. We won’t take any of that control away from you nor will we tell you how you must build your app or what you must call things. We’re just removing legacy plumbing that’s bloating the inside of the framework and serves no purpose. (i.e. the PluginService, getPlugin(), getMyPlugin(), WireBox "ColdBox:Plugin:pluginName injection DSL, etc) and we’re making WireBox be the way that your CFCs are created and supplied to you.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

#14

I understand that part already Brad, what I am asking or trying to grasp is how this affects the naming and placement of things like this in say ContentBox where the Widget is actually a plugin. How does this then affect something like this and what we already have as plugins now.

Does this mean all plugins from now on will no longer work and have to be rewritten, or are you saying that the changes will not affect how we write these now? I do understand that going forward we will be using getModel() instead and is this going to be slowly deprecated or is it going to be just removed?

#15

Plugins won’t have to be rewritten. At worst, some injection annotations might need to be added if your plugin was using logbox, cachebox, etc that were being auto-injected into them.

Honestly, we haven’t fully decided how this will affect widgets. Any feedback or suggestions are welcome at this point.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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