wow... very interesting. I think basically this boils down to the fact
that we expect concrete classes to have their own constructor (not
sure where that sits in terms of "best practice").
If anyone on the list has comments about this, I'd love to hear them.
In earlier versions of ColdSpring, we called init on any CFC without
even checking, but obviously that pissed a few people off. Now we
check to see if it's there before calling it, but we're not checking
in parent classes (so Adam's inherited init() would never get called).
Pretty easy fix, but I'd still like to hear others thoughts.
-Dave
On 12/2/05, Adam Crump <[EMAIL PROTECTED]> wrote:
>
> Not sure if this is planned/intentional/known or not, but the autowire
> appears to miss inherited methods. For example:
>
> I have a base cfc of
> <cfcomponent name="dao" output="false" hint="I am the dataaccess object for
> common queries">
> <cfscript>
> variables.myDsn = createObject('component',
> 'com.amkor.global.dao.dsn').init();
> </cfscript>
>
> <cffunction name="init" returntype="dao" access="public"
> output="false" hint="I initilize this object">
> <cfargument name="dsn" type="com.amkor.global.dao.dsn"
> required="false" default="#variables.dsn#" hint="I am the cf data source to
> use for the data connection">
> <cfset variables.myDsn = arguments.dsn />
> <cfreturn this />
> </cffunction>
>
> <cffunction name="setDsn" returntype="void" access="public"
> output="false" hint="I set the cf dsn name to use for queries">
> <cfargument name="dsn" type="com.amkor.global.dao.dsn"
> required="true" hint="I am the new value to set the dsn to" />
> <cfset variables.myDsn = arguments.dsn />
> </cffunction>
>
> <cffunction name="getDsn" returntype="com.amkor.global.dao.dsn"
> access="public" output="false" hint="I set the cf dsn name to use for
> queries">
> <cfreturn variables.myDsn />
> </cffunction>
>
> </cfcomponent>
>
> and the subclass of
>
> <cfcomponent name="someDAO" extends="com.amkor.global.dao.dao"
> output="false" hint="I am the data access object for something">
>
> <cfscript>
> variables.selectList = "somefields";
> </cfscript>
>
> <!--- <cffunction name="init" returntype="com.amkor.global.dao.dao"
> access="public" output="false" hint="I initilize this object">
> <cfargument name="dsn" type="com.amkor.global.dao.dsn"
> required="false" default="#variables.dsn#" hint="I am the cf data source to
> use for the data connection">
> <cfset variables.myDsn = arguments.dsn />
> <cfdump var="#variables.myDsn.getDsn()#"
> />
> <cfabort />
> <cfreturn this />
> </cffunction>
> --->
> <cffunction name="read" returntype="query" access="public"
> output="false" displayname="Read" hint="I read a record from the persistance
> layer">
> <cfargument name="someId" type="string" required="true"
> default="Invoice Request Id" hint="I am the id to retrevie" />
> <cfset var aSomethingReadSelect =
> queryNew(variables.selectList) />
> <!--- <cfdump
> var="#variables.myDsn.getDsn()#" />
> <cfabort /> --->
> <cfquery name="aSomethingReadSelect"
> datasource="#variables.myDsn.getDsn()#">
> somequery
> </cfquery>
> <cfreturn aSomethingReadSelect />
> </cffunction>
>
> </cfcomponent>
>
>
> In the coldspring config I have the following entries
>
> <bean id="sqlDsn" class="com.amkor.global.dao.dsn" singleton="true"
> lazy-init="false" autowire="no">
> <constructor-arg
> name="dsn"><value>dsn_Name</value></constructor-arg>
> </bean>
>
> <bean id="someDAO" class="myApp.someDAO" singleton="true" lazy-init="false"
> autowire="no">
> <constructor-arg name="DSN"><ref
> bean="sqlDsn"/></constructor-arg>
> </bean>
>
>
> Everything loads fine, but when I call the read method on the someDAO cfc,
> the variables.myDsn.getDsn() returns empty string. When I uncomment the
> init method in the someDAO.cfc, the variables.myDSN.getDsn() returns the
> proper value of dsn_Name.
>
> This is a result of the way cf is handling inheritance. What happens is the
> init method is not in the array in the functions key returned from
> getMetaData(). It is instead in the array in the extends.functions key.
> See the attached exampleDump.zip for a cfdump of what it looks like. I know
> the autowire stuff as well as the entire core is still in alpha, so if the
> need exists, I could take a stab at resolving this over the weekend.
>
>
>
> Best Regards,
>
> Adam Crump
> Sr. Analyst - Programmer
> Web Services - ICS
> Amkor Technology
>
>
>
