I have been playing with Coldbox for a while now (loving it) and have
built some plugins.
I was wondering what people's views are regarding Plugins VS straight
Components.
The upside of Plugins is that you get a whole pile of infrastructure
access to Coldbox due to the inheritance. Things like logging,
several core methods, and such. This is attractive but can anyone see
a "downside" to this?
I am not talking about "bean" type objects that you may reuse in non-
coldbox applications - moreso building "service" type components in
Plugins instead of the raw component mechanism. Case in point, the
MailService is a Plugin.
Personally I think I am going to build more things as Plugins - but
just want to get other people's opinions.
In ColdBox 3, we have eliminated the limitation and coupling of inheritance. Therefore your plugins are in reality CFCs. However, in 3.0 what we do is that we decorate the component at runtime and morph it into a ColdBox plugin. So you can use all the infrastructure inheritance provided to you without the coupling. We call this pseudo-inheritance, well at least that is the name I give this pattern
You will also find a virtual super scope called: $super, which you can use to create overrides.
So you can use all the infrastructure inheritance provided to you
without the coupling.
Well, that's not really true. You still have the coupling - to the
infrastructure that you depend on. All you've done is remove the
inheritance dependency and replaced it with a mixin dependency. In
order to reuse such components outside ColdBox, you still need to
mixin that infrastructure somehow
We call this pseudo-inheritance, well at least that is the name I give this pattern
So - I could removed the "extends" attribute (as I am running M5) and
the plugins will still work?
In any case, I was more just trying to get opinions from people on
creating a generic "XXXXService" component versus an "XXXXXService" as
a Plugin.
Obviously, even with the decorator model, if I write code that depends
on those methods being available, the mechanism by which they appear
in the component is somewhat irrelevant (in that writing a Component
with no inheritance should give me some level of portability - whereas
using a CB Plugin AND using the Plugin methods, ties me to the
framework regardless).
Not a complaint - I love the Plugins. Just was hoping for a community
feel on it.
Obviously - if can "extend" my "component" AND make it a "plugin" - I
get the best of all worlds.
So - I could removed the “extends” attribute (as I am running M5) and
the plugins will still work?
Yes!!
In any case, I was more just trying to get opinions from people on
creating a generic “XXXXService” component versus an “XXXXXService” as
a Plugin.
Obviously, even with the decorator model, if I write code that depends
on those methods being available, the mechanism by which they appear
in the component is somewhat irrelevant (in that writing a Component
with no inheritance should give me some level of portability - whereas
using a CB Plugin AND using the Plugin methods, ties me to the
framework regardless).
Not a complaint - I love the Plugins. Just was hoping for a community
feel on it.
Obviously - if can “extend” my “component” AND make it a “plugin” - I
get the best of all worlds.
Regards,
Gary
Yes, the idea behind the inheritless approach was to make them more portable if you decide NOT to use the mixin methods and the pseudo-inheritance model. Also, you could write simple CFC libraries, drop them and use them seamlessly as plugins.
HOwever, if you want to take FULL advantage of the framework you can then use the exposed methods and components for a more richer plugin architecture. Therefore, now in 3.0 the developer has the choice of using simple CFCs or more richer decorated CFCs.
Hi,
Im rarely using plugins, im only making a plugin if it is something
coldbox-specific it has to do.. like when i want to extend coldbox
with some functionality.
I have been thinking about this lately, and i wonder why this plugin
thing (and other handy things in coldbox) is not made as a bonus-set
of cfc's that comes with coldbox but is not dependent on coldbox.
I would have liked it much better that coldbox came with a coldspring
xml that injects all the cfc's (plugins) that come with codlbox, that
i can use as a parent coldspring container for example.
It just seems wrong to me to make all your cfc's so dependent on
coldbox. Its like a new type of cfc, the coldbox cfc.
If you see coldbox as an extension of the coldfusion language and you
will always use it, then i understand.
Yes, I agree with what you are saying (and "Hi - long time no talk").
I think, by moving it to a mixin model now, it means your actual
component can have an inheritance tree and Coldbox does not get in the
way of that (unless, of course, there are clashes with method names).
@Klass
I don't really play in the "dependency injection framework" space
(maybe that should say "yet") but I believe Coldbox has the ability to
incorporate container use. Lightwire (for example).
@Dorioo
Totally agree with that. In then end, things depend on other things.
We make decisions every day that cause us to create dependencies in
our code. As a developer of many many years, the important thing to
know is what those dependencies are and how likely you may need to
refactor them.
@All
The benefit I see with Coldbox plugins is that a lot of the core
things that I am likely to do are already available to me in Plugins.
So, given I have decided that Coldbox is going to be the framework I
am using for our development group (moving forward) then I dont think
it is a bad idea to create dependencies on it... So.... there will be
more Plugins
I see your point but like Gary said, you trade dependencies. In my years of experience, there will always be dependencies, but you always want to minimize them or make them so abstract that they could be interchanged correctly.
In the case of plugins, they can have dependencies directly to ColdBox so you can leverage the library (coldbox) that you are using. You are building on top of an already chosen infrastructure. If you do not want to do that, then build domain objects that deal with the problem at hand and use a container (wirebox,coldspring or lightwire) to manage them.
The point is that there is no wrong or right approach, you have to take an educated decision if you want to create a plugin that is a simple CFC or a CFC that will use ColdBox specific functionality.
Well, i dont agree you create dependencies when using coldspring,
thats the whole point of IOC, to not create dependencies.
With dependencies i mean, keep the black-box principle of objects:
objects are not aware of their surroundings, just of what is supplied
to them: other objects, defined by interfaces or whatever.
The first thing i learned at university that objects are black boxes.
So i like to keep to that.
Plugins take in stuff from coldbox, like if you use
getSetting(approot)... then this method has to be supplied by coldbox
(by extension or mixin, doesnt matter). So this breaks the black box
principle.
If i inject this setting with a setter using something like <property
name="folder" value="{approot}"> then the blackbox principle is taken
care of. This setter does not HAVE to be called by coldspring, it can
be any IOC, or it can just be set programmatically. So i dont see any
dependency on coldspring here..
About whats right or wrong, that probably not the right way to put it.
The way im suggesting takes more work, and might potentially be slower
in performance.. i would justify the approach taken by these means...
i totally understand you dont want to go through that extra work for
certain projects..
Though, i think a framework should not take shortcuts, as its the base
of an application, and lately the plugin way of doing things is
something a bit shitty, as there are very useful plugins in coldbox
but i cant just use them in my coldbox-independent objects...as then i
would make them dependent on coldbox (a way around this would be to
specify interfaces for these plugins i think).
Fair enough. I see the dependency you’re referring to. Academically, I agree that it does create a dependency on coldbox. Practically, though, I only see it as an issue if you plan to change the base framework of a given application. So, you have to ask yourself: how likely is it that someone will ask you to change the base framework? And do they really have a compelling reason to want that?
For me, I draw the line at the base framework. If I’ve chosen one for a given application, then I want to focus on using it and its features to make me more productive and not on trying to abstract dependencies to it.
In theory, it’d be great for an application to be independent of any of the frameworks it uses. In practice, I think there are many more benefits to marrying the base framework of the app than on trying to abstract its dependencies.
I think you are missing the point Klass. Plugins are meant to be coupled to the framework, as that is your environment. You are not building a domain object or business rule where the rules apply. You are building on the agreement of your surroundings and environment.
It’s like you have wordpress and you create a specific plugin to work with wordpress. Now, how the plugin is constructed is where you can apply your OO and analysis . You can make a plugin proxy in your objects so the functionality is independent of the surrounding environment, you can use interfaces, abstractions etc.
So again, the point that plugins is a “shitty” approach as you say, I completely disagree. They have their purpose and their set responsibilities. They are to enhance the FRAMEWORK and help in your applications. They are a way to help you extend functionality not available in the core framework.
Again, since you prefer to be completely decoupled, then there are ways to definitely do this, without saying that such a functionality is not worth it, I do not agree, and they are definitely NOT shortcuts.
