Updating Mach-ii app to use ColdSpring - Approach and Risks?

[Brian Meloche]

Another topic of discussion at the conference was ColdSpring. We are
not using it in either our new enterprise app, or the new portions we
have recently added to our legacy enterprise app that use Mach-ii,
including a portion I am retrofitting from our new app back into our
old right now.

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

[Dan Wilson]

Brian,

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

[Brian Meloche]

Thanks for the response, Dan.

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.

[Kurt Wiersma]

How do your listeners currently access your service objects?

--Kurt

[loosec...@yahoo.com]

Coldspring injects your listeners with your service objects.

On Feb 5, 11:56 am, "Kurt Wiersma" <kwier...@gmail.com> wrote:
> How do your listeners currently access your service objects?
>
> --Kurt
>

[loosec...@yahoo.com]

You can use ColdSpring with your Mach application as little or as much
as you wish.
If you don't put your components in the coldspring.xml file then they
won't be injected
and you just use them as your normally would with your createObject
calls.

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

[Richard Kroll]

> 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

[loosec...@yahoo.com]

I thought about doing the inheritance method but didn't want to impose
more work on the team. Getting them used to Mach-II, ColdSpring, and
CFUnit all at one time has been an undertaking, especially since they
were not
used to really using components before and just doing cowboy
development in .cfm files. Baby steps.

On Feb 6, 10:18 am, "Richard Kroll" <rich...@sitemanageware.com>
wrote:

[loosec...@yahoo.com]

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:

[Prem Radhakrishnan]

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

--
A programmer is a device to turn coffee into code

[Kurt Wiersma]

Right now I don't have tutorial to go with AppBooster. I have plans to do a series on my blog but have gotten busy with Mach II development. :) Perhaps after we get dev cycle done I could do a series of in depth posts. What kinds of things would you like to see covered in a AppBooster safari?

--Kurt

On 2/21/07, Prem Radhakrishnan <godsmus...@gmail.com> wrote:

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



--

[Prem Radhakrishnan]

What would be really cool is something like ---

here is an AppBooster App and its in Mach II

Now we are going to convert this into a MachII ColdSpring app and heres how we do it

for beginners you know and then move forward from there to more complicated apps using ColdSpring


and I spend a lot of time on it yesterday and i think I have it figured out, all you need to do is setup the services.xml file and then use the ColdSpring plugin with the correct parameters , is this a generally correct assuption?

Thanks Kurt,
Prem

[Kurt Wiersma]

Prem,

Yes you are right it just a matter of setting up the services.xml file and then pasting in the config for the ColdSpring Mach II plugin into your Mach II config file. Usually the biggest hurtles for most people are understanding what problems ColdSprings solves and then architecting/implementing a service layer into their applications. My experience is that most people start out with out a service layer and do all their business logic in their listeners/controllers.

During your learning if you see anything else about Mach II, ColdSpring, or AppBooster that would be nice to see in a tutorial let us on this list know can we can consider it for our next wave of documentation. :)

--Kurt

[Prem Radhakrishnan]

Hi Kurt,
Heres a quick question

In the user listener config this is wat happens
<cfcomponent output="false" extends="MachII.framework.Listener" displayname="userListener" hint="I am a user listener.">

    <cffunction name="configure" access="public" returntype="void" output="false">
        <!--- <cfset variables.serviceFactory = getProperty("serviceFactory")>
        <cfset variables.userService = serviceFactory.getBean("userService")> --->
    </cffunction>


on the other hand in the role listner

    <cffunction name="configure" access="public" returntype="void" output="false">
        <cfset variables.serviceFactory = getProperty("serviceFactory")>
        <cfset variables.roleService = serviceFactory.getBean("roleService")>
    </cffunction>

doesnt the ColdSpring plugin make the services available automatically ? so from what I understand the userListener is correct and the roleListener has some extra code?
 Please confirm

Thanks
Prem

[Prem Radhakrishnan]

Well, I was working with appbooster 1 till now and i just downloaded appbooster 3 and things are quite a bit different there. I am going to try to figure this one out now.

[Kurt Wiersma]

Yes, ColdSpring will inject dependencies into the Mach II listeners. What you saw in the code commented out in the userListener was my example that I show people what features the Mach II ColdSpring plugin has. Before the plugin had that feature you had to grab the CS bean factory in your listeners configu method and then grab the service(s) you wanted.

Hopefully that makes more sense.

--Kurt

[drfishflan]

Hi kwiersma

I was hoping you would be able to email me a copy of your Appbooster sample application for Machii.

Thanks very much

Alex Tait