[coldspring-dev] help

[Chris Scott]

Before we all get too crazy trying to figure out how to have an object become auto wired with the bean factory, ColdSpring already provides a ServiceLocator type utility to manage the location of the bean factory for you, in a provided scope. So lets say you want to place a bean factory in application scope, you can use the utility's default location like this: <!--- create the utils cfc and the bean factory ---> <cfset var bfUtils = createObject("component","coldspring.beans.util.BeanFactoryUtils").init()/> <cfset var bf = createObject("component","coldspring.beans.DefaultXmlBeanFactory").init()/> <!--- load your beans ---> <cfset bf.loadBeansFromXmlFile([configFile.xml])/> <!--- ok now put bean factory in a default location ---> <cfset bfUtils.setDefaultFactory('application', bf) /> <!--- OR, put in a named location ---> <cfset bfUtils.setNamedFactory('application', 'myFactory', bf) /> So now we can use the same component from inside any cfc. Like so, maybe in an init method: <cfset var bfUtils = createObject("component","coldspring.beans.util.BeanFactoryUtils").init()/> <cfset var bf = bfUtils.getDefaultFactory('application') /> <!--- OR ---> <cfset var bf = bfUtils.getNamedFactory('application', 'myFactory') /> Now you can get your bean factory from anywhere. The mach-ii plugin already uses the BeanFactoryUtils cfc and uses the key 'beanFactoryPropertyName', defined as a parameter to the plugin, but if it doesn't exist, it uses the default location. I spoke to Joe about using the same system in ModelGlue, so it should be consistent there too. Spring for Java has the same mechanism, and it is used in the SpringContextLoaded (Servlet or Listener, sorry the actual class name is not quite that). So in Spring for Java, the 'standard' way to locate beans in a web app is by accessing the factory through the utility.  I think overall, I would like to see an approach like this favored over trying to hack a system for injecting the bean factory into objects, because it is just a lot simpler and more flexible. Plus it opens up ColdSpring managed beans to be shared across not only application instances, but different types of applications as well. A good example being a remote interface for a mg/m2 app. OK, hope that can help! Chris On Mar 9, 2006, at 7:09 PM, Paul Roe wrote: You guys are awsome, and like I was saying I won't go about putting this practice into production, it's just how I like to learn. I go down a path untill I find the end then start another. The info that Sean gave me will definetly give me something to explore and in the process learn a lot about coldsprings capabilities. Thanks again. On 3/9/06, Dave Ross <[EMAIL PROTECTED]> wrote: Spring has a BeanFactoryAware interface that, when implemented by a Spring-managed bean, will cause the BeanFactory to inject itself into the bean it's creating (you must implement a setBeanFactory(...) method). We haven't done anything similar in ColdSpring, but this blurb from the Spring docs might give you an idea why: "While there are cases when this capability is useful, it should generally be avoided, since it couples the code to Spring, and does not follow the Inversion of Control style, where collaborators are provided to beans as properties." -Dave On 3/9/06, Sean Corfield <[EMAIL PROTECTED]> wrote: > On 3/9/06, Paul Roe < [EMAIL PROTECTED]> wrote: > > Based on your responses I'm left with the conclusion that it doesn't matter > > if what I'm trying to do is possible or not, I just shouldn't do it.  Right > > now I am just experimenting with this framework, getting to know it if you > > will. It is good to learn these best practices that you all are providing, > > however, I guess my real question is still left unanswered. Is this > > possible, without hacking the framework? > > Well, it's not how the framework is designed to be used so it is > deliberately non-trivial to make it work the way you are trying to do > it. > > I can think of several ways to achieve what you want that bend the > framework to greater or lesser degrees. > > First off, let me just reiterate that you should not be trying to have > your business object use the factory to get other objects -- you > should tell ColdSpring how to inject those other objects directly into > your business object. > > Having said that, let's look at ways to solve your problem. > > 1. Add a setter to your business object, setBeanFactory(), and call it > directly in your application once you've asked ColdSpring for that > business object: > >    busObj = application.cs.getBean("busy"); >    busObj.setBeanFactory(application.cs); > > 2. Create a wrapper for the bean factory first. Declare a factory > object in cs.xml with a type factorywrapper.cfc - that CFC just has > set/get-BeanFactory() methods. Have your application ask ColdSpring > for the wrapper at startup and then call the setBeanFactory() method > (essentially as above). Declare all your business object to take a > wrapper as the constructor-arg (which is now a managed object so CS > *can* find it). The business object can then call its own > getBeanFactory().getBean("whatever") to get new beans: > >    wrapper = application.cs.getBean("factory"); >    wrapper.setBeanFactory(application.cs); > > Then: > >    busObj = application.cs.getBean("busy"); > > There may be other similar variants. > > In other words, the application is the only part that knows about > ColdSpring directly. > > Finally, this is not how Spring / ColdSpring was designed to be used > and you shouldn't be doing it this way. > -- > Sean A Corfield -- http://corfield.org/ > Got frameworks? > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > >