10 Replies Latest reply on Jun 29, 2006 12:51 PM by Newsgroup_User

    Avoid Evaluate in this case?


      I am invoking a webservice that returns Java entry arrays for ldap user information.

      To display the name from each entry i have this code:

      <cfloop index="intIndex" from="0" to="#arraylen(topOfOrg.getEntryArray().getEntry())-1#">
      <cfoutput>#directReports.getEntryArray().getEntry(evaluate(intIndex)).getName()#</cfoutpu t>
      </cfloop>

      Should i avoid using evaluate in this case? And how could I if it is an option?

      Thanks for any thoughts/ideas.
        • 1. Re: Avoid Evaluate in this case?
          Dan Bracuk Level 5
          I'll assume your cfinvoke tag has a returnvariable attribute. Let's call it myArray.

          <cfoutput>
          <cfloop index = "ii" from = "0"
          to = arraylen(myArray)>
          #myArray[ii]#
          etc
          • 2. Re: Avoid Evaluate in this case?
            MikerRoo Level 1
            Use JavaCast ("int", intIndex) instead of evaluate(intIndex).
            • 3. Avoid Evaluate in this case?
              quote:

              Use JavaCast ("int", intIndex) instead of evaluate(intIndex).


              Thanks MikerRoo that worked and feels faster.

              KC
              • 4. Re: Avoid Evaluate in this case?
                MikerRoo Level 1
                If speed is an issue, you should precompute the loop condition outside of the cfloop (almost always a good idea anyway).

                That is...
                <CFSET iNumbOfEntries = arraylen (topOfOrg.getEntryArray().getEntry()) - 1>
                <cfloop index="intIndex" from="0" to="#iNumbOfEntries#">
                ...


                1 person found this helpful
                • 5. Re: Avoid Evaluate in this case?
                  Level 7
                  > If speed is an issue, you should precompute the loop condition outside of the
                  > cfloop (almost always a good idea anyway).

                  That's good advice for a for() loop, but redundant for a <cfloop>. CF only
                  evaluates the expression the first time, anyway, for a <cfloop> (so in
                  effect it automatically does what you suggest).

                  --
                  Adam
                  1 person found this helpful
                  • 6. Re: Avoid Evaluate in this case?
                    Level 7
                    > Use JavaCast ("int", intIndex) instead of evaluate(intIndex).

                    I'm missing something. Why do you need *either* of those options, instead
                    of just using intIndex directly? <cfloop> indexes are already Java ints,
                    aren't they?

                    --
                    Adam
                    • 7. Re: Avoid Evaluate in this case?
                      MikerRoo Level 1
                      quote:

                      Originally posted by: Newsgroup User
                      That's good advice for a for() loop, but redundant for a <cfloop>. CF only
                      evaluates the expression the first time, anyway, for a <cfloop> (so in
                      effect it automatically does what you suggest).

                      --
                      Adam


                      I had forgot about that design flaw in cfloop.
                      But, since it is contrary to how just about any other language operates, it is a good habit to keep the precompute (makes debugging easier too).


                      • 8. Re: Avoid Evaluate in this case?
                        MikerRoo Level 1
                        quote:

                        Originally posted by: Newsgroup User
                        > Use JavaCast ("int", intIndex) instead of evaluate(intIndex).

                        I'm missing something. Why do you need *either* of those options, instead
                        of just using intIndex directly? <cfloop> indexes are already Java ints,
                        aren't they?

                        --
                        Adam



                        First, I give KC the benefit of the doubt -- that he would not use evaluate if he didn't need it.

                        Second, CF7 to Java seems to do a poor job of reliably passing anything but strings to Java. I've had to cast ints to ints a few times myself -- for no good reason.

                        Third, the member function getEntry() may be overloaded. Then Javacast is needed so that CF can pick the right function.

                        Fourth, I heard (but have not tested) that functions with defaulted parameters, like getEntry(), need Javacast!

                        Finally, JavaCast costs nothing measurable, in the way of performance, to use. If our code looks more complex we get paid more, right? ;-P

                        1 person found this helpful
                        • 9. Re: Avoid Evaluate in this case?
                          Thanks all for the feedback/discussion.

                          I'm not an expert yet... just graduated with a bachelors in business adminstation with a CIS focus in december. That means i had about 3 programming classes and one web design class that had about 4 weeks on coldfusion. But ever since i was exposed to coldfusion i have enjoyed it. Landed a job after graduation as a web master of a site with coldfusion 5.0 applications.

                          I recommened a new server and upgrade to coldfusion mx 7. And started redesigning our site and applications. Its been fun and challenging.

                          This week i had the idea to make a dynamic org chart. Our corporation has a active directoy lookup web service, so I set out to consume it in coldfusion. Took some trial and error but i got consumption to work....

                          I don't know java well, but the web service documentation said returns java entry array objects. Took some trial and error again to get the data out of the objects once they were returned. But got that working, then i expanded my querie to return multiple arrays within the object so i had to loop over it (i assume this is a resonably efficient way to get at each array).

                          My original logical line of code was to use:
                          <cfloop index="intIndex" from="0" to="#arraylen(directReports.getEntryArray().getEntry())-1#">
                          <cfoutput>#directReports.getEntryArray().getEntry(intIndex).getName()#</cfoutput>
                          </cfloop>
                          This code returns this error: "The selected method getEntry was not found."
                          coldfusion.runtime.java.MethodSelectionException: The selected method getEntry was not found.

                          In response to that i set evaluate around the intIndex and it worked, but i had read evaulate was a costly operation, so i asked for help here. And got the excellent javacast alternative.

                          The webservice return variable is directreports, a java object i believe, and it has a method to get to the result set of EntryArray and then each array in the result set has methods to reveal my data. Like name, work phone, job title, etc.

                          Its a simple application, but everyone loves it so far. Thanks all!
                          • 10. Re: Avoid Evaluate in this case?
                            Level 7
                            I think you've started out in the industry with a good attitude and a good
                            approach to learning stuff.

                            And given your error, you are indeed experiencing what Mike said about CF
                            having a tendency to treat everything as a string, unless one makes it
                            *very* obvious that it's not.

                            I suspect if you changed your JavaCast ("int", intIndex) to intIndex*1, it
                            would also work, as CF would trig that intIndex is a number. But I'd stick
                            with the former solution, as it's more clear as to why you're doing.

                            --
                            Adam