On 3/8/06, Cody Caughlan <[EMAIL PROTECTED]> wrote: > I havent actually used ColdSpring yet but I saw that it had a nifty object, > "AutoWire" which conveniently populates an object (bean) via its setters > using a struct and its keys as "input".
AutoWire.cfc was the original implementation of Model-Glue autowiring - it's a Model-Glue controller. Now that Model-Glue supports autowiring ColdSpring in its core, AutoWire.cfc is obsolete. > However, as soon as I tried to populate a Bean which > "extends" another Bean (and has no functions of its own, e.g. they all exist > in the Base bean class), my method failed. Correct. See my recent thread about walking the inheritance tree in the archives! :) > To support an arbitrary level > of extends and all types of objects, I modified the method to use recursion Ugh! :) Look at how ProxyBeanFactory.createProxyInstance() does this to see a better way to walk the inheritance tree. > 1) Did I just re-invent the wheel? In looking at ColdSpring 0.5.0, AutoWire > doesnt support beans which are not base beans. Is this logic somewhere else > in the framework and I just missed it and did work for no reason? You missed it, see above. > 2) If it doesnt exist, would ColdSpring benefit from me donating this code > back to the community? Do you care or even want this? See the recent long thread about walking the inheritance tree. We specifically do *not* want to do this in most circumstances. I posted an analysis on March 7th (yesterday) about this but I'll re-post here: ---------- Forwarded message ---------- From: Sean Corfield <[EMAIL PROTECTED]> Date: Mar 7, 2006 12:02 AM Subject: [coldspring-dev] Walking the inheritance chain... To: [email protected] On 3/6/06, Chris Scott <[EMAIL PROTECTED]> wrote: I'm pretty sure I also agree in principle, but I think we're going to have to look at the changing landscape of coldfusion. OK, I've done some analysis of the files in ColdSpring that touch metadata and what they do with it: AopProxyUtils: clone() Not clear whether this should walk the inheritance hierarchy. Right now, no code in ColdSpring uses clone() (the AOP advice code used to but no longer does). Since I don't know whether cloning should handle complex objects, I don't know whether this should walk the hierarchy but since it's unused, it can be left alone. AutoWire: addControllerProxy() Obsolete. Since nothing should now be using this, it doesn't matter whether it walks the hierarchy or not! BeanDefinition: getDependencies() Not clear that this should walk the inheritance hierarchy. I'm not even sure yet exactly what this bit of code does. I'll revisit this in a few days! coldspringPlugin: resolveDependencies() Since the targets are listeners, plugins and filters and they *will* have concrete setters, this does *not* need to walk the inheritance hierarchy. Leave as-is, do not walk the hierarchy! DefaultXmlBeanFactory: constructBean() Only touches init() - probably doesn't need to walk the hierarchy. If we accept that all classes should declare init() as best practice then we can safely leave this code alone (question: what about complex generated code where init() is inherited? That is the situation for *some* Reactor-generated code...). Needs a little more research... ProxyBeanFactory: createProxyInstance() Needs to walk hierarchy so you can proxy complex objects. In order to proxy complex objects - like Reactor-generated gateways etc - we need to walk the hierarchy. This is pretty clear cut so I committed the change for this! RemoteFactoryBean: createRemoteProxy() Probably should walk hierarchy. I haven't made the change to this yet but I think it should match the ProxyBeanFactory logic. Kurt? ThrowsAdviceInterceptor: buildMethods() Use concrete types so no walking My sense is that advice objects will be concrete, especially for exception handling, and therefore we do not need to walk the hierarchy. So, in summary: - BeanDefinition.getDependencies() - no idea, more research needed. - DefaultXmlBeanFactory.constructBean() - more research needed (but leaning to not changing this). - ProxyBeanFactory.createProxyInstance() - change required (committed). - RemoteFactoryBean.createRemoteProxy() - probably ought to match ProxyBeanFactory.createProxyInstance(). - Others - no change needed. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood
