asked on

issue with coif and evaluate function

I have the following logic:

<cfloop from="1" to="#norecs#" index="thisrow">

<cfset text_seq = "#evaluate("ts" & thisrow)#">
<CFSET "alt_type#text_seq#" = "#evaluate("alt_type" & text_seq)#">
<cfif ("alt_type#text_seq#" eq "") or ("alt_type#text_seq#" eq 'text1')>
including code for text_inc 

<cfelseif "alt_type#text_seq#" eq 'spacer'>
this is a spacer
<cfelse>
we are undefined and therefore proceeding to debug mode 
my alt_type#text_seq# = "#evaluate("alt_type" & text_seq)#" 
</cfif>

</cfloop>

1) I am passing the #norecs# and this is working correctly
2) I am passing the #ts# and this is working corruptly,
3) there are 6 records, and the the first four (in the database, are blank for the alt_type, and the last two are "spacer1"
4) The alt_type should resolve to the number of the record/instance (for example, alt_type34) and thus in turn, should be set to it's corresponding hidden field value from the form.
5) I am then executing conditional logic to run application logic based on whether it is blank or if it is set to 'spacer'
6) since everything should resolve to something, I have a debug set to show any record that is set to anything differently.
7) everything defaults to the error - through by debug code shows what I would expect:

we are undefined and therefore proceeding to debug mode
my alt_type34 = ""

we are undefined and therefore proceeding to debug mode
my alt_type38 = ""

we are undefined and therefore proceeding to debug mode
my alt_type39 = ""

we are undefined and therefore proceeding to debug mode
my alt_type47 = ""

we are undefined and therefore proceeding to debug mode
my alt_type49 = "spacer"

we are undefined and therefore proceeding to debug mode
my alt_type50 = "spacer"

I know that is must be something simple - but I am legitimately confused

btintermedia

ASKER

I mistyped - the ts is working correctly not corruptly, lol

ASKER CERTIFIED SOLUTION

Brijesh Chauhan

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

_agx_

>> <cfif ("alt_type#text_seq#" eq "")

Because you're comparing the literal string "alt_type34", not the value of a variable named #alt_type34#. To access the value, just use array notation: scopeName["keyName"]

ie
#FORM["alt_type"& text_seq]# ... or
#VARIABLES["alt_type"& text_seq]# .. or
#URL["alt_type"& text_seq]#

Brijesh Chauhan

@_agx_, I have already made that change in the authors code in comment 36314904 ??

_agx_

Also, you'd simplify the code if you stored the value in a variable and reused it. Rather than re-evaluating the dynamic variable value every time.

ie

<cfset altType = trim(variables["alt_type"& text_seq])>
<cfif altType eq "" or alt_type eq 'text1')>
including code for text_inc 

<cfelseif altType eq 'spacer'>
this is a spacer
<cfelse>
we are undefined and therefore proceeding to debug mode 
my alt_type#text_seq# = "#altType#" 
</cfif>

_agx_

@bri - Yes, but mine was an explanation of why the original problem wasn't working. IMO understanding code mistakes is just as helpful. Sometimes more so, as it teaches you what not to do in the future.

>> cfset Variables['alt_type#text_seq#'] = "#evaluate("alt_type" & text_seq)#" />

May as well be consistent and remove all of the evaluate() calls. There's no need for it.

gdemaria

ugh, not for points.

I wrote the same thing agx did and THEN read saw it there! So since I wrote it, I'll post it...

I assumed you are working with "Form" scoped variables, if that is wrong, you need to change "FORM" to whatever scope the alt_typets1, alt_typets_2 variables belong to.

I also grabbed the value from the alt_typets1 variable only once and placed it into a temporary variable called "TheValue" then used theValue from that point on.

<cfloop from="1" to="#norecs#" index="thisrow">
      
    <cfset theValue = trim(form["alt_type" & "ts" & thisrow])>  <!---- get the value just once ----->
    
    <cfif len(theValue) eq 0 or theValue is "text1">
        including code for text_inc<br />
        <!--- <cfinclude template="q_text_inc_text1.cfm"> --->
    <cfelseif theValue is "spacer">
        this is a spacer
    <cfelse>
        we are undefined and therefore proceeding to debug mode<br />
        the value for row #thisrow# = "#theValue#"<br /><br />
    </cfif>
    
</cfloop>

Open in new window

_agx_

>> I wrote the same thing agx did and THEN read saw it there!
Yeah but with two people saying the same thing, you know it's right ;-)

gdemaria

It's a shame the author didn't choose your answer, I hope he will at least use it as it's a much cleaner solution.

Rule to code by: anytime you feel like typing "evaluate()" turn off the monitor until the feeling goes away.

_agx_

>> anytime you feel like typing "evaluate()" turn off the monitor until the feeling goes away.

rofl! I just wish the authors of the legacy app I'm working with today took that advice :/

btintermedia

ASKER

To all:

I am really grateful for all the input. Not just on this question, but others that I have posted here. I did try the several of the solutions - but the one that I chose worked. I tried to investigate why the other did not - and I'm still not sure. Admittedly, I am getting better at programming all of this stuff - but even this is still just a bit over my head, though I am pretty sure that I understand it. I am going through and making the change regarding setting the value once and not reevaluating again and again. I know that there are different philosophies regarding awarding points - and I do often split points, but this was a really complicated problem for me, and this worked. On more complicated issues (complicated for me) I will usually award the full points to one that makes it work. However though, in almost every situation, there is valuable input from almost everybody - it makes it very difficult to choose.

_agx_

>> tried to investigate why the other did not - and I'm still not sure

If you ever have further questions, always feel free to ask. Without knowing more, I'd guess it was a scoping issue. The variables in the original code were unscoped, so we all guessed between the common ones: variables, form, url, .... I'd be happy to assist if you want help getting things to work.

>> I know that there are different philosophies regarding awarding points
I appreciate your response :) but please don't misunderstand. The comments here weren't about points. Most experts strive to provide not just "something" that works, but code that's clean and maintainable too. Both for the person asking, and those reading the PAQ's. So if there's a cleaner way to do something, like there is here, of course we hope you'll use it! But the choice is always yours.