Twitter: raymondcamden


Address: Lafayette, LA, USA

Ask a Jedi: Impact of whitespace and script based CFCs

08-26-2009 2,899 views ColdFusion 15 Comments

Henry asks:

Does CF9 script style CFC still needs to set attribute output=false for component and function?

In my - admittedly - very limited testing, the answer appears to be no. I created a component with a large amount of white space in both the function and around it as well:

view plain print about
1component {
2
3
4public string function sayHello() {
5
6
7
8
9
10
11
12
13
14
15
16    return "Hello World!";
17
18}
19
20
21}

I duplicated this component but added output="false" to both the component and method:

view plain print about
1component output="false" {
2
3
4public string function sayHello() output="false" {
5
6
7
8
9
10
11
12
13
14
15
16    return "Hello World!";
17
18}
19
20
21}

To test then I created an instance of both and wrapped the sayHello call:

view plain print about
1<cfset badWS = new testws()>
2<cfset goodWS = new testws2()>
3
4<cfoutput>
5Testing bad: -#badWS.sayHello()#-<br/>
6Testing good: -#goodWS.sayHello()#-<br/>
7</cfoutput>

The result was the exact same. No additional white space from the creation of the CFC or the call either. I even tested making an instance of the first CFC with createObject, just to see if it made a difference, and it did not. Of course, it isn't like the output="false" argument is ignored. If you write a CFC method that outputs directly to the screen, then it does matter. Consider:

view plain print about
1public function sayHello2() { writeOutput("hello2!"); }

That function will work just fine, but if you modify it a bit...

view plain print about
1public function sayHello2() output="false" { writeOutput("hello2!"); }

Now you have a useless function. The output="false" will suppress the writeOutput>

15 Comments

  • Commented on 08-26-2009 at 8:00 AM
    My opinion on this new scripting stuff is so torn, on the one hand I think it's really cool, makes the language feel somewhat more grown-up or something, I don't quite know, but on the other hand the reason I first started using CF was because of the tag based nature and how intuitive it felt as someone who has only previously dealt with html.
  • Commented on 08-26-2009 at 8:04 AM
    Tags have there place on the presentation layer. To me it just feels better writing business logic in a less verbose more natural environment. The great thing is though developers have a choice so if its not for you don't worry, continue writing code the way you do now!
  • Commented on 08-26-2009 at 8:18 AM
    I'll ditto Dan. If the script stuff doesn't work for you, don't use it. :)
  • Commented on 08-26-2009 at 9:27 AM
    The reason you get no extra whitespace using script-based CFCs is this: The only way a script block can output to the buffer is using writeOutput()... so if you have an all-script CFC, you won't get any whitespace. If you have a template with cfscript tags, you'll get the whitespace outside the cfscript tag, but you won't get any whitespace from the code inside the script tag.
  • Commented on 08-26-2009 at 9:36 AM
    Re: White Space

    Interesting.

    In CFAdmin what is your 'Enable Whitespace Management' set to? By default in CF9 its now checked and I wonder if that changes things.

    Re: Script and Tags

    We've got the best of both worlds now :)
  • Commented on 08-26-2009 at 9:41 AM
    Good catch there. I forgot that in CF9 this is turned on by default. I turned it off, but it didn't impact anything.

    @Jared: Yeah, I believe you are 100% right, and it is kind of obvious now, but at the same time, good to confirm.

    I tend to be anal about output="false" in my CFCs, but won't be bothering with it when i do script based ones.
  • Commented on 08-26-2009 at 10:10 AM
    I don't believe that the whitespace management setting in the CF Admin should have any effect on script... script can't just output text unless you tell it to by using writeOutput() . Whitespace management is an artifact of a tag-based world built exclusively to output to the browser and extended to build objects.
  • Commented on 08-26-2009 at 10:12 AM
    Ooops, I said that already. Heh.

    I cannot get teh brainz to fully engage today. ;)
  • Commented on 08-26-2009 at 12:59 PM
    Thank you for answering my question, jedi! :D
  • Commented on 08-26-2009 at 2:38 PM
    This is pretty much the behavior I would expect from a script-based CFC, but it's certainly nice to see it actually tried out and confirmed.

    Does anyone know if it's possible to call custom tags using script-based syntax? If so, I wonder what would happen then.

    Thanks!
  • Commented on 08-26-2009 at 2:41 PM
    You can't. If your custom tag didn't need to support children, or wrapping, it would take two seconds to wrap cfmodule into a UDF. This would allow you to do: module("foo.cfm",{arg1=x,arg2=y}).
  • Commented on 08-26-2009 at 2:45 PM
    Well, maybe not two seconds. ;) It would be difficult to tell if the tag returned a value that you would then pass back. However, if you want to replace a known custom tag call, then you could definitely write a quick UDF wrapper for it.
  • Adam Cameron #
    Commented on 08-29-2009 at 1:05 AM
    G'day
    Just on the whitespace thing. There's still a slight use case for specifying output=false on script-based functions & components.

    If the script code includes a tag-based file, the whitespace from the tag-based file still outputs (if whitespace management is off, natch).

    It'd be questionable form to be including files from within a function, but it's still possible, so maybe worthwhile tucking this thought away in the corner of ones brain.

    --
    Adam
  • Commented on 08-29-2009 at 8:41 AM
    @Adam: Wow, good find there. Thank yoU!
  • Commented on 08-29-2009 at 9:14 AM
    Hey Adam, good call. I can see that being an important function in a framework or DSL intended to process files into output, for example, and it would be perfectly fine in that case. I mean, there are probably a 100 places where this.include("/template/path.cfm") would be a viable method call, and in that case you have a totally valid point. :)

Post Reply

Please refrain from posting large blocks of code as a comment. Use Pastebin or Gists instead. Text wrapped in asterisks (*) will be bold and text wrapped in underscores (_) will be italicized.

Leave this field empty