You need to go read about Servlets and JSP.  What you'll notice about
the second stream content is that it doesn't contain the word "start",
which is present in the first stream's content.  Why, you say? 
Because the custom tag actually executes as a separate process, with a
different PageContext object, and a separate environment.  So there's
really two separate buffers, one for the root request, and one for the
subrequest (if I can call it that).  The latter gets injected into the
former at the end of the subrequest (the closing CF_TAG).

So if you fire a flush inside your custom tag, on the page content,
you'll actually be flushing the internal buffer, and won't touch the
request's main buffer at all.  I mispoke earlier about how the
PageContext flushing hack would work, because I hadn't thought it all
the way through.  I'd said that it would flush the pre-custom tag
content, but that's wrong.

But even if CF does let you do a "Send the buffer now" on the main
request from inside a custom tag's body, you still have the issue
where the content preceeding the CFFLUSH tag inside the custom tag
seems like it should be flushed, even though it won't be.  By simply
throwing an error, you alleviate the subtle issues that can arise from
people assuming behaviour that isn't really there, because they don't
understand about the stack of buffers.

Does that make sense?  It's worth mentioning here that I have no more
access to CF's internal workings than you do, everything I've said is
based on observed behaviour and knowledge about how JSP/Servlet
applications work.

cheers,
barneyb

On Thu, 24 Feb 2005 18:55:01 -0000, Adam Cameron <[EMAIL PROTECTED]> wrote:
>  
> 
> Barney, can you please explain something to me... 
> 
> Here's some sample code: 
> 
> <!--- caller.cfm ---> 
> start<br /> 
> <cfset stDebug = structNew()> 
> <cfset stDebug["1. bufferBeforeTag"] =
> getPageContext().getOut().getString()> 
> <cf_tag> 
>         text before capturing buffer<br /> 
>         <cfset stDebug["2. bufferInsideTag"] =
> getPageContext().getOut().getString()> 
>         text after capturing buffer<br /> 
> </cf_tag> 
> text outside closing tag<br /> 
> <cfset stDebug["3. bufferAfterTag"] = getPageContext().getOut().getString()>
> 
> <cfdump var="#stDebug#"> 
> 
> <!--- tag.cfm ---> 
> <cfif thisTag.ExecutionMode eq "end"> 
>         <cfset thisTag.generatedContent = ucase(thisTag.generatedContent)> 
> </cfif> 
> 
> Now... this is a bit curious.  It kind of seems like CF is putting the
> content within the custom tags into the buffer as soon as it encounters it,
> but when it gets to the closing tag, finds its got some work to do, says
> "ooh... heck... better grab that stuff out of the buffer again... um...
> uppercase it.... cool, that was easy... back in the buffer you go. 
> Hopefully no-one will notice I put you in the before I'd finished processing
> it". 
> 
> Is that's what's happening?  Surely not.  There's some vagary there that I'm
> not seeing. 
> 
> Shouldn't the custom tag processor not be putting anything into the buffer
> until the closing tag is hit?  I mean... it *knows* there's a closing tag
> "hasEndTag" or whatever it is, so why not wait for it? 
> 
> This whole "there's no way of knowing" is a problem CF seems to make for
> itself by dipping in and out of the buffer! 
> 
> To me this <cfflush> thing is making a complex situation out of a simple
> one.  A buffer is a binary system: stuff is either in it, or not in it. 
> That's it.  <cfflush> should simply say "right, you lot... off to the
> browser".  If it's in the buffer... it's gone.  If it's not... well, it's
> not relevant.  CF seems to be creating some situation of "yeah, but this
> stuff is *almost* in the buffer (in fact, if you look closely, it *is* in
> the buffer) and I reckon they're going to want this stuff, so you better
> wait for a tick...". 
> 
> Whereas I might be inclined to not be second-guessing anything, and if I got
> told "send the buffer now", I'd simply... send the buffer... now.  And not
> put anything in said buffer until it's actually ready to go. 
>  
> 
> Can you pls clarify? 
>  
> 
> -- 
> Adam 


-- 
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/

Got Gmail? I have 50 invites.

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]

Reply via email to