Aug 1 2008

I want CFGoto!

Posted by Joe Rinehart at 11:09 AM
20 comments - Categories: ColdFusion MX

Sometimes when I'm working in ColdFusion, I get a little fed up with trying to do things that aren't quite functions, aren't quite objects, and aren't even justifiable custom tags. Things like rendering a specific pod in a stack, or programatically choosing which pods to render.

I'd really like a solution from a much older form of thought to show up in ColdFusion: I'd like to be able to have a given .cfm template jump to any line within itself, run some code, then jump back. This'd include any template it <cfinclude>'d, allowing me to use variables in my <cfinclude /> to do some really dynamic stuff.

I think I'd call it <cfgoto />, and it could jump to any <cfmarker />. Seriously, it's in many high-level languages, why can't we do it in ColdFusion?

This'd be so nice:

<cfloop from="1" to="#arrayLen(pods)#" index="i">
<!--- Forks to the block of code that renders a pod --->
<cfgoto marker="renderPod_#pods.getName()#

<!--- Pod rendering code <cfgoto />'s back to here --->
<cfmarker name="podRenderLoop" />
</cfloop>

Comments

Brian Kotek

Brian Kotek wrote on 08/01/08 11:22 AM

I totally agree, Joe. It's simple things like this that CF is missing that sometimes make me wonder about its long-term viability. GOTO has been around forever, and even though it gets a bad rap, in almost all cases a nice long block of procedural code with some markers in it will run much faster than OO-based code. In the end, raw performance trumps maintainability and modularity every time.
Rachel Lehman

Rachel Lehman wrote on 08/01/08 11:55 AM

Hmm, Really Dynamic Stuff sounds great. To bad the RDS acronym is already taken!
Maybe you can add a viewState.goTo() method in Model-Glue?
Barney

Barney wrote on 08/01/08 12:07 PM

You mistyped your example, I think? Shouldn't it be this:

<cfset i = 1 />
<cfmarker name="loop" />
<!--- Forks to the block of code that renders a pod --->
<cfgoto marker="renderPod_#pods.getName()#

<!--- Pod rendering code <cfgoto />'s back to here --->
<cfmarker name="podRenderLoop" />
<cfif i LTE arrayLen(pods)>
<cfgoto marker="loop" />
</cfif>

I'm all for it, we need to talk to Sean, Gert, et al about getting that in the spec.
Gary Gilbert

Gary Gilbert wrote on 08/01/08 12:14 PM

Chaos would reign!

There are enough badly written programs out there already without introducing the goto command!

I remember my basic days with line numbers and everything and the goto statement...shiver...
Dan Wilson

Dan Wilson wrote on 08/01/08 12:27 PM

I don't get it.

GOTO Seems like a horrible idea.

If I refactor your code into a switch statement, I get the same result.

<cfloop from="1" to="#arrayLen(pods)#" index="i">
<!--- Forks to the block of code that renders a pod --->
<cfgoto marker="renderPod_#pods.getName()#

<!--- Pod rendering code <cfgoto />'s back to here --->
<cfmarker name="podRenderLoop" />
</cfloop>

Becomes

<cfloop from="1" to="#arrayLen(pods)#" index="i">
<!--- Forks to the block of code that renders a pod --->
<cfswitch expression="renderPod_#pods.getName()#

<!--- Pod rendering code <cfcases/>'s back to here --->
<cfcase value="renderPod_foo">
<h1>I am a pod</h1>
</cfcase>
<cfcase value="renderPod_bar">
<h1>I am also a pod</h1>
</cfcase>

</cfswitch>

</cfloop>



What am I missing?

DW
duncan

duncan wrote on 08/01/08 12:35 PM

<cfgoto> tag considered harmful!
Brian Kotek

Brian Kotek wrote on 08/01/08 12:57 PM

Ah but the cfcase values have to be static values. One could easily envision dynamic marker names, so that one could alter, at runtime, not only the goto values but the marker labels as well. So one could change what marker the goto directs program flow to, but also change the marker values so that the same marker can be called from goto tags specifying different marker names.

Any developer that doesn't see exactly what this would mean probably should consider changing professions.
Dan Wilson

Dan Wilson wrote on 08/01/08 1:00 PM

I hear wyoTech has a nice motorcycle repair program. I'm calling them right now.
Brian Kotek

Brian Kotek wrote on 08/01/08 1:05 PM

You don't fool me for a second, Dan. I think you see EXACTLY what it would mean. ;-)
Mike Rankin

Mike Rankin wrote on 08/01/08 1:25 PM

While you're at it, don't forget <cfgosub>. That way we could move a chunk of code out to it's own file. It would be nice to segregate it from the main line of code, "encapsulate" it, if you will.

And lets bring back punched tape! It would be really cool to be able to stick your program in your pocket and not leave a copy of it anywhere.

Hmmm.... I wonder if I can get a punched tape scanner for my iPhone....
Mike Rankin

Mike Rankin wrote on 08/01/08 1:28 PM

While you're at it, don't forget <cfgosub>. That way we could move a chunk of code out to it's own file. It would be nice to segregate it from the main line of code, "encapsulate" it, if you will.

And lets bring back punched tape! It would be really cool to be able to stick your program in your pocket and not leave a copy of it anywhere.

Hmmm.... I wonder if I can get a punched tape scanner for my iPhone....
Sean Corfield

Sean Corfield wrote on 08/01/08 1:49 PM

And then we need to borrow COBOL's ALTER statement where you could have a GO TO statement in a paragraph like this:

SOME-JUMP-PARAGRAPH.
GO TO DEFAULT-MARKER.

Then elsewhere in the program you could say:

ALTER PARAGRAPH SOME-JUMP-PARAGRAPH TO PROCEED TO DIFFERENT-MARKER.

Next time you execute SOME-JUMP-PARAGRAPH, it will GO TO DIFFERENT-MARKER instead of DEFAULT-MARKER. That sort of dynamic modification of code at runtime is incredibly powerful and it really helped when you were enhancing large legacy applications because it was so easy to patch the flow of control.
Brian Kotek

Brian Kotek wrote on 08/01/08 1:57 PM

High performance AND easy to maintain FTW!
Peter Bell

Peter Bell wrote on 08/01/08 2:39 PM

Dang - my calendar is screwed up. I'm seeing August 1st - guess I'm four months ahead.

Unseasonably warm for spring . . .
Mike Rankin

Mike Rankin wrote on 08/01/08 4:36 PM

I just saw this on futurama last night:

10 HOME
20 SWEET
30 GOTO 10

Sorry about the earlier double post. I refreshed out of (bad) habit.
Dale Fraser

Dale Fraser wrote on 08/02/08 4:57 AM

I have to disagree, never had the need and I was an old Business Basic programmer who used GOTO and GOSUB like there was no tommorow.

If you finding yourself needing this, I'd suggest you get someone to review your coding technique.
Dale Fraser

Dale Fraser wrote on 08/02/08 4:59 AM

PS: Something wrong with this form.

The submit button is not visible, hidden under the bottom grey banner I think as is half of the Remember my information.

This is on Vista, ie7

PS: I submitted by pressing enter in the captua since I cant get to the button
Joe Rinehart

Joe Rinehart wrote on 08/04/08 12:26 PM

Hi all,

This was a joke. Sorry if it wasn't obvious enough, and +1000 points to the Brian, Sean, and Barney for playing along without even being prompted!
Elliott Sprehn

Elliott Sprehn wrote on 08/17/08 5:35 AM

What's funny about this is that the JVM actually supports goto, though only for bytecode offsets. That's how all looping constructs and a lot of other things get implemented.

So they could probably add goto support to the compiler fairly easily with switch statements for the dynamic jumps.

String t1 =_invoke( PODS, "getName", new Object[0]);
switch( GoTo("renderPod_" + t1) ) {
case 1:
// bytecode for goto 58.
default:
throw new UndefinedJumpTargetException();
}

...

//<cfmarker name="podRenderLoop" />
// bytecode offset 58
Sarah

Sarah wrote on 08/21/08 10:14 AM

Rachel should get points too:

"viewState.goTo() method in Model-Glue" !!

Write your comment



(it will not be displayed)







Categories

Monthly Archives

Search Archives

Favorite Links