Sorry - this is a pretty simple application and I probably should not
have replied under this thread.
1) We are not calling eventContext.displayView() anywhere in this application.
2) Yes, there is not a single <cfsetting> tag in this application.
3) There seems to be a difference in whether mach-ii.cfc vs.
mach-ii.cfm is used. I'm confused about this code (it's similar in
both files):
<cfprocessingdirective suppresswhitespace="true"><cfcontent
reset="true" /><cfsetting enablecfoutputonly="true" /><cfset
application[MACHII_APP_KEY].appLoader.getAppManager().getRequestHandler().handleRequest()
/><cfsetting enablecfoutputonly="true" /></cfprocessingdirective>
Why are we:
a) resetting the output buffer (this breaks the ability to include
a mach-ii app inside any other cfml construct (mach-ii "owns" the
request at that point)
b) setting enablecfoutputonly="true" twice? I think this is why I
have to turn it off twice.
Thanks!
-Dave
On Mon, Aug 30, 2010 at 1:25 PM, Peter J. Farrell <[email protected]> wrote:
> I tried to do an include on a page using <cfinclude> like your example
> and I don't have any issues using CF8 -- it outputs just fine. There
> are few questions I have for you:
>
> * What engine and version of CFML engine are you using?
> * Where are you calling eventContext.displayView() from? It's against
> the API to do this from within a view -- yes, it's available in the
> request scope but we've always said not to do this.
> * Have you done a search for <cfsetting> in your application?
> * The two enablecfoutputonly="false" statements indicate that
> enablecfoutputonly="true" have been turned on twice before it gets to
> this part of the request. I think it's silly, but you enablecfouputonly
> is not a simple flag on Adobe CF. If you turn it on twice, you have to
> turn it off twice to get back to square one.
> * Another place people have been caught on this is calling displayView
> from an event-filter
>
> .pjf
>
> Dave Ross said the following on 08/30/2010 11:39 AM:
>> Peter,
>>
>> We're having this (or similar) issue with a few of our apps against
>> 1.8.0 stable. I'm confident that we don't use <cfsetting
>> enablecfoutputonly="true"/> anywhere in the app - but our situation
>> may be a bit unique since this particular mach-ii application is
>> "included" from a "wrapper" index.cfm published by a content mgmt
>> system. Basically, the "wrapper" looks like this:
>>
>> <html>
>> <body>
>> <h2>Hello</h2>
>> <cfinclude template="/MachIIApp/index.cfm"/>
>> </body>
>> </html>
>>
>> With 1.8, we lose the markup above and only the output of the app is
>> sent to the browser... you never get a "hello".
>>
>> The only workaround we've found is this adjustment to the wrapper:
>>
>> <cfsavecontent variable="myContent">
>> <cfinclude template="/MachIIApp/index.cfm"/>
>> </cfsavecontent>
>> <cfsetting enablecfoutputonly="false"/>
>> <cfsetting enablecfoutputonly="false"/>
>> <html>
>> <body>
>> <h2>Hello</h2>
>> <cfoutput>#myContent#</cfoutput>
>> </body>
>> </html>
>>
>>
>> Note the "double" cfsetting tags. Totally weird. Any ideas as to where
>> we would look for a better fix (perhaps within the application rather
>> than our "wrapper")? Same behavior is seen on all versions tested
>> above 1.8.0.
>>
>> Thanks!
>>
>> -Dave
>>
>> On Thu, Aug 5, 2010 at 12:39 PM, Peter J. Farrell <[email protected]> wrote:
>>
>>> jilly said the following on 08/05/2010 10:08 AM:
>>>
>>>> Does eventContext.displayView() change the enablecfoutputonly setting
>>>> to "yes" in 1.8? I had to add:
>>>> <cfsetting enablecfoutputonly="no">
>>>> to my layout view to get the content to display correctly after
>>>> upgrading from 1.6!
>>>>
>>>>
>>>>
>>> Yes, we added some aggressive whitespace handling in Mach-II 1.8.
>>> However, problems like this are caused by extra <cfsetting
>>> enablecfouputOnly="xxx"> in an application code base. This tag doesn't
>>> work exactly right because saying enablecfouputonly="true" *twice* and
>>> doing enablecfouputonly="false" only *once* doesn't turn off the output
>>> only part. They have to be done in pairs. So if it's turned on twice;
>>> it has to be turned off twice.
>>>
>>> Based on your question, it sounds like you are dynamically via the
>>> EventContext calling a view from a filter or something. Is that true?
>>> If so, then this ticket applies to you:
>>>
>>> http://trac.mach-ii.com/machii/ticket/522
>>>
>>> Can you share some code? It could be as simple as the "output"
>>> attribute on the function being set to false or left off entirely (the
>>> "output" attribute is not a true boolean in Adobe CF it is a tripod).
>>>
>>> .pjf
>>>
>>> --
>>> You received this message because you are subscribed to Mach-II for CFML
>>> list.
>>> To post to this group, send email to [email protected]
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> For more options, visit this group at
>>> http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
>>>
>>> ***New URLs as of April 29th, 2010***
>>> SVN: http://svn.mach-ii.com/machii/
>>> Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to Mach-II for CFML list.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
>
> ***New URLs as of April 29th, 2010***
> SVN: http://svn.mach-ii.com/machii/
> Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
>
--
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
***New URLs as of April 29th, 2010***
SVN: http://svn.mach-ii.com/machii/
Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
