• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

"setter" methods not working in CF11

New Here ,
Jun 01, 2015 Jun 01, 2015

Copy link to clipboard

Copied

I recently migrate code from a CF8.01 instance to a freshly installed/updated CF11 instance. As I was going through some testing I ran into an issue where the "setter" methods within a CFC are not setting the values of the locally scoped instance data within the CFC. The exact same code works on CF8. I read a couple articles which made reference to a new attribute of the cfcomponent tag (accessors=true) that will implicitly create getters/setters. I am not using this attribute so I'm not sure if that has anything to do with it. Below is some sample code.

test.cfm:

<cfscript>

   myObj = CreateObject('component', 'WorkUpBean').init();

   myObj.setTypeID(2);

</cfscript>

<cfdump var = "#myObj.getTypeID()#">

WorkUpBean.cfc:

<cfcomponent name="WorkUpBean" displayname="WorkUpBean" hint="I am a workup bean">

<cfscript>

  local = StructNew();

  local.TYPE_ID = 0;

</cfscript>

<cffunction  name="init" access="public" output="false" returntype="WorkUpBean">

   <cfargument name="TYPE_ID"   required="false" type="numeric" default="#local.TYPE_ID#" />

   <cfset setTypeID(Arguments.type_id)>

</cffunction>

<cffunction name="getTypeID" access="public" output="false" returntype="numeric">
   <cfreturn local.TYPE_ID />
</cffunction>

<cffunction name="setTypeID" access="public" output="false" returntype="void">
   <cfargument name="TYPE_ID" type="numeric" required="true" />
   <cfset local.TYPE_ID = arguments.TYPE_ID />
   <cfreturn />
</cffunction>

</cfcomponent>

I am at my wits end here. I need this working like yesterday! Any help would be greatly appreciated.

Views

416

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Expert , Jun 02, 2015 Jun 02, 2015

It should behave in the way you expect. Strictly speaking, you should replace every occurrence of local with variables.local

If it still fails, you should file a bug report.

Votes

Translate

Translate
Community Expert ,
Jun 02, 2015 Jun 02, 2015

Copy link to clipboard

Copied

It should behave in the way you expect. Strictly speaking, you should replace every occurrence of local with variables.local

If it still fails, you should file a bug report.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 04, 2015 Jun 04, 2015

Copy link to clipboard

Copied

You hit the nail on the head BKBK! More specifically, the issue was due to the "local" scope introduced in CF9 that was stepping on my declared variables. I spent some time with Charlie Arehart on this and he was able to quickly identify that as the issue. Instead of specifying Variables. (which would have worked) I simply renamed my declared variables to something else and all is well with the world. Because I was migrating from CF8 to CF11 and the "local" scope was introduced in CF9, the issue wasn't readily apparent (to me that is).

What's still a bit puzzling is why it didn't work as is. From what I've been reading and as BKBK pointed out it should have...

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jun 04, 2015 Jun 04, 2015

Copy link to clipboard

Copied

LATEST

I know what Charlie means. However, in my opinion, adding the keyword, local, to the language was not a good idea.

The ColdFusion Team intended it to have the same functionality as var . So, within the context of a function,

var myParam = 1;  // (1)

is roughly equivalent to

local.myParam = 1;  // (2)

This is bad design for at least 2 reasons. Firstly, it is duplication. Secondly, it has side-effects, hence introduces complexity. By side-effects, I mean that, by declaring (1), a simple-type variable, you also, without consenting to, automatically declare (2), a complex-type variable.

In any case, the 'local' we are talking about here is defined within the context of a function. Whereas, your 'local' is defined in the pseudo-constructor area of the component.

In fact, I have seen lots of code where a variable is given the name 'var' in the component's pseudo-constructor without any problems at all. It seems to be a common habit particularly of colleagues arriving from other programming languages.

You could test this. Just for laughs. Replace every occurrence of 'local' in your original code with 'var', and see what happens.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation