After attending several presentations where ColdSpring was discussed,
and private conversations at the conference, I am convinced that us
not using ColdSpring was a mistake that we need to start addressing
ASAP, probably during our next release. Thoughts?
What are the benefits to NOT using ColdSpring and sticking with things
as is? Currently, we have DAOs, gateways (we don't call them that)
and some services defined/initialized in our Application.cfm. We have
to create objects throughout our CFCs to call each other. Especially
after attending Rob Gonda's Object Factories presentation, the concept
of using ColdSpring to help us create object factories made a lot of
sense. This was also more solidified by reading Sean Corfield's
presentation on the subject:
http://corfield.org/articles/cfobj_factories.pdf
Like in the previous message, I'll state we're very risk averse, and
if introducing ColdSpring into our application produces any risks, it
won't happen. It would only happen if risk can be limited.
My approach, assuming I can get approval to do so, would be to
introduce CS into one of our less used sub applications, so we can
introduce it into the application but contain the risk. As CS is
proved successful in the lesser sub application, we'd start to update
the other sub applications to use ColdSpring. Does this approach make
the most sense? Do you have another approach to suggest? I've used
this same type of test introduction of new code in our previous,
procedural version of our application, so I am confident I could do
the same here and mitigate the risk. I am assuming our other
mach--ii.xmls would be unaffected until we start using the ColdSpring
plugin, and start using it throughout our CFCs.
If I can get the approval, I don't see us doing it for a few months,
when we start working on a 1.1 release of our application.
Going back to my previous thread, can we introduce ColdSpring
independent of going to a Mach-ii 1.1.1 core, or would you recommend
going to ColdSpring only after updating our Mach-ii core (currently at
1.1)?
--
Sincerely,
Brian Meloche
brianmeloche at gmail dot com
http://www.brianmeloche.com/blog/
User Group Manager,
Cleveland Adobe Users Group,
http://www.clevelandmmug.org
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org
I hear you on the risk adverse Client / Employer.
The benefit of not using ColdSpring is you will be using straight-up
ColdFusion. There is no learning curve in your architecture.
The benefits of using ColdSpring are, changes to your application
functions, or paths, or other configuration are centralized in an XML
file and can be evaluated in one file. This helps a lot when adding
new components, or switching out one component for another.
Of all the frameworks, ColdSpring appears to be the most stable and
the most consistant. Having ColdSpring helps out by reducing the lines
of code in your app, it reduces the hard-coded dependencies when
dealing with components and truthfully, for the common ColdSpring
featues, it is a snap to learn.
HTH
Dan Wilson
That was also my take on ColdSpring. Once you take out the AOP
aspects, which it seems only Chris Scott understands :-), it's dead
simple. Actually, the AOP aspects also seem pretty compelling for
logging and security, too.
On Feb 5, 11:56 am, "Kurt Wiersma" <kwier...@gmail.com> wrote:
> How do your listeners currently access your service objects?
>
> --Kurt
>
Also, ColdSpring favors setter injection over constructor injection so
I have found that
you need to have empty constructors for your components (unless they
can be set with
constructor-args in the coldspring.xml with hard-coded values or mach-
ii properties) and
rely on the setters to set everything. Also if you have to create a
component manually
you can call the coldspring bean factory and get the component from it
without having to
call createObject.
One other side note is that the dependency injection method really
shines when you can
use interfaces like the java Spring can. With it, you can substitute
any implementation in
your spring configuration file and never change any code. Well with
ColdFusion there are
no interfaces so you cannot do this but if you are willing to trade
off some type checking
you can set the type of your setters that are injected to type="any"
thus allowing you to
change the component type in the coldspring.xml file. If you also do
this with other methods
it has the added benefit of not tying your component names to a fixed
hierarchy in your webroot.
Some may disagree with me on this one for purist reasons.
> brianmeloche at gmail dot comhttp://www.brianmeloche.com/blog/
> User Group Manager,
> Cleveland Adobe Users Group,http://www.clevelandmmug.org
You can kind of hack ColdFusion to get interface style functionality if
you plan correctly. You create a component that has the correct method
signature and have all child objects extend the 'interface' component.
Using this method you do not have the ability to have a parent-child
relationship as well as implementing an interface (but CF is full of
trade-offs).
I generally put a CFTHROW into the body of all methods of my
'interfaces' that I do not have a generic implementation for. This
method is the closest that I've been able to come to get reasonable
functionality similar to interfaces.
Rich Kroll
On Feb 6, 10:18 am, "Richard Kroll" <rich...@sitemanageware.com>
wrote:
On Feb 6, 10:18 am, "Richard Kroll" <rich...@sitemanageware.com>
wrote:
--
A programmer is a device to turn coffee into code
Hey All,
Back after hibernation with the other caps that I wear. Im sure someone has asked the question before. I found the AppBooster application from Kurt that is a starter for ColdSpring and Mach II and I have been reading on ColdSpring a lil more. I was wondering if there is a tutorial of some sort that goes parallel to that App. I did find the presentation useful as well.
Thanks
Prem
On 2/6/07, loosec...@yahoo.com < loosec...@yahoo.com > wrote:
One other note is that you will still have to put fully-qualified
component names
in your code even though they are only a parent component. As you
say, tradeoffs.
On Feb 6, 10:18 am, "Richard Kroll" < rich...@sitemanageware.com >
wrote:
> > Well with ColdFusion there are
> > no interfaces so you cannot do this but if you are willing to trade
> > off some type checking
> > you can set the type of your setters that are injected to type="any"
> > thus allowing you to
> > change the component type in the coldspring.xml file. If you also do
> > this with other methods
> > it has the added benefit of not tying your component names to a fixed
> > hierarchy in your webroot.
> > Some may disagree with me on this one for purist reasons.
>
> You can kind of hack ColdFusion to get interface style functionality if
> you plan correctly. You create a component that has the correct method
> signature and have all child objects extend the 'interface' component.
> Using this method you do not have the ability to have a parent-child
> relationship as well as implementing an interface (but CF is full of
> trade-offs).
>
> I generally put a CFTHROW into the body of all methods of my
> 'interfaces' that I do not have a generic implementation for. This
> method is the closest that I've been able to come to get reasonable
> functionality similar to interfaces.
>
> Rich Kroll
--
Hi kwiersma