The way the current SVN build works is this:
1) When addTraceStatement is called, the arguments are pushed into the
logWriter implementation. This happens regardless of the debug or reload
status.
2) The current implementation of logWriter does some checks to see whether
and how to log the passed data:
<cffunction name="write" output="false">
<cfargument name="eventContext" />
<cfargument name="logMessage" />
<!---
We want to log complex values when debug is set to verbose so
convert it to a simple value with dump.
--->
<cfif variables.debugMode IS "verbose" AND
isSimpleValue(arguments.logMessage.message) IS false >
<cfsavecontent variable="arguments.logMessage.message"><cfdump
var="#arguments.logMessage.message#" /></cfsavecontent>
</cfif>
<!---
Log simple values when debug isn't disabled'
--->
<cfif variables.debugMode IS NOT "none" AND
isSimpleValue(arguments.logMessage.message) IS true >
<cfset arrayAppend(eventContext.log, arguments.logMessage) />
</cfif>
</cffunction>
So, this pushes responsibility down to the logWriter as to how to log items
or not. You could provide your own implementation of logWriter, and add it
to your ColdSpring.xml with the bean ID of modelGlue.logWriter and then have
custom logging as you please.
The logWriter currently has the value of debug passed in at creation time.
The the logMessage argument of logWriter.write() has the EventContext along
with the original arguments to addTraceStatement:
So valid values are: logMessage.type, logMessage.message, logMessage.tag,
logMessage.traceType
You could do any sort of processing you want based on those values. So, one
way to always log something, would be to use the type of AlwaysLog in your
addTraceStatement call, then look for that in your logWriter.
Thoughts?
DW
On Tue, Jan 19, 2010 at 7:27 AM, Chris Blackwell <[email protected]> wrote:
> Hi Dennis,
>
> I'm not sure I personally would find it useful, i just wondered if others
> might.
>
> But how about allowing an optional argument to the message that could turn
> it on, even if it were off in the mg config?
>
> <!-- this message overrides the debug setting in your modelglue
> configuration -->
> <message name="ModelGlue.disableDebugging">
> <!-- optional, default=true -->
> <argument name="disabled" value="false" />
> </message>
>
> i think its also worth being clear that we're no longer suppressing the
> debug output but actually disabling the process all together, hence the
> change to the message name.
>
> maybe there's room for both modelglue.suppressDebugOutput and
> modelglue.disableLogging? i can foresee circumstances where a custom
> logrenderer might log to a file or db and output to the page but for an ajax
> event you'd want to simply supress the page output and keep the logging
> enabled
>
> -Chris
>
>
>
> 2010/1/18 Dennis Clark <[email protected]>
>
>> The way the framework works now, if the debug config setting is turned off
>> the framework does not call the log renderer. Adding a request-level "force
>> debugging" feature would require changing this. At this point the change
>> would be fairly small, but may become more involved when if/when we optimize
>> the trace code to eliminate unneeded calls for performance.
>>
>> Chris, if you find forced debugging to be a desirable feature please file
>> an enhancement request on Trac.
>>
>> Implementing the "force debugging" functionality would be the same
>> regardless of how the feature is exposed.
>>
>> From an API perspective, forcing debug output through an XML extension
>> would involve adding a new attribute (e.g. forceDebug="true") or a new value
>> (e.g. debug="suppress|force|default"). Using a builtin controller, we could
>> simply have the same controller listen to a second message (e.g. <message
>> name="ModelGlue.forceDebugging" />).
>>
>> Note that with the controller approach, you could have "suppress
>> debugging" and "force debugging" both turned on for a request. In this case,
>> the log renderer would be called but the log render would return an empty
>> string, so no debug output would be returned. This may or may not be the
>> desired outcome.
>>
>> Cheers,
>>
>> -- Dennis
>>
>> On Mon, Jan 18, 2010 at 12:13 PM, Chris Blackwell <[email protected]>wrote:
>>
>>> just to be awkward, if debug is turned off in the modelglue config bean,
>>> would either of these methods allow you to turn it on only for a specific
>>> event? and if not, might that be a desirable behaviour?
>>>
>>> -Chris
>>>
>>>
>>>
>>> On 18 Jan 2010, at 16:42, Dan Wilson <[email protected]> wrote:
>>>
>>> That isn't a bad way to do it either and might actually help out later on
>>> when we add portcullis to the mix.
>>>
>>> We should discuss the implementation details of this and make sure we are
>>> on the same page. Where do you foresee this living inside the framework?
>>>
>>> DW
>>>
>>> On Mon, Jan 18, 2010 at 10:51 AM, Dennis Clark < <[email protected]>
>>> [email protected]> wrote:
>>>
>>>> While I agree that debug output breaking JSON and XML output is an issue
>>>> for many Model-Glue applications, I'm not convinced that it's worth
>>>> extending the ModelGlue.XML API to solve this when solving this with the
>>>> existing API is fairly straightforward and does not take that much more
>>>> code
>>>> over the approach presented here.
>>>>
>>>> All that I see that we *really* need is a predefined controller that
>>>> listens to a special message to disable debugging. A good name for this
>>>> message would be "ModelGlue.suppressDebugging" (to match the
>>>> request.modelGlueSuppressDebugging variable that it sets).
>>>>
>>>> Revised example:
>>>>
>>>> <event-handler name="eventHandlerWithDisabledDebug">
>>>> <broadcasts>
>>>> <message name="ModelGlue.suppressDebugging" />
>>>> </broadcasts>
>>>> </event-handler>
>>>>
>>>> Revised event type example:
>>>>
>>>> *
>>>> <event-type name="hasNoDebug">
>>>> <before>
>>>> <message name="ModelGlue.suppressDebugging" />
>>>> </before>
>>>> </event-type>
>>>>
>>>> I'd much prefer we be conservative with extending the XML APIs as the
>>>> size of the API affects the learning curve of Model-Glue, and it's much
>>>> harder to shrink an API than it is to expand it.
>>>> *
>>>> *
>>>> *
>>>> What do others think?
>>>> *
>>>> *
>>>> -- Dennis
>>>>
>>>>
>>>> On Thu, Jan 14, 2010 at 9:00 PM, Dan Wilson < <[email protected]>
>>>> [email protected]> wrote:
>>>>
>>>>> I just checked in a pretty cool enhancement for Model-Glue into SVN.
>>>>>
>>>>> *Ticket:* <http://trac.model-glue.com/ticket/350>
>>>>> http://trac.model-glue.com/ticket/350
>>>>> *Title:* Disable Model-Glue debug information for certain events
>>>>> Example:
>>>>>
>>>>> What if you have an event that generates JSON or XML or another
>>>>> structured format and you never ever ever want Model-Glue debugging to
>>>>> munge
>>>>> it up?
>>>>>
>>>>> Well now you can simply decorate your event-handler or event-type with
>>>>> disableDebug=true and Model-Glue debugging will vanish. In both code
>>>>> examples below, the Model Glue debugging will shut itself off for that
>>>>> request. Thus, your structured data won't be affected by Model-Glue
>>>>> debugging.
>>>>>
>>>>>
>>>>> *Examples:*
>>>>>
>>>>> * **<event-handler name="eventHandlerWithDisabledDebug"
>>>>> disableDebug="true">*
>>>>>
>>>>> *Or using Event Types:*
>>>>>
>>>>> <event-type name="hasNoDebug" disableDebug="true">
>>>>> <before>
>>>>> </before>
>>>>> </event-type>
>>>>>
>>>>> <event-handler name="eventHandlerWithEventTypeOfDisabledDebug"
>>>>> type="hasNoDebug">
>>>>>
>>>>>
>>>>> DW
>>>>>
>>>>>
>>>>> --
>>>>> “Come to the edge, he said. They said: We are afraid. Come to the edge,
>>>>> he said. They came. He pushed them and they flew.”
>>>>>
>>>>> Guillaume Apollinaire quotes
>>>>>
>>>>
>>>>
>>>>
>>
>> --
>> Model-Glue Sites:
>> Home Page: http://www.model-glue.com
>> Documentation: http://docs.model-glue.com
>> Bug Tracker: http://bugs.model-glue.com
>> Blog: http://www.model-glue.com/blog
>>
>> You received this message because you are subscribed to the Google
>> Groups "model-glue" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]<model-glue%[email protected]>
>> For more options, visit this group at
>> http://groups.google.com/group/model-glue?hl=en
>>
>
>
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<model-glue%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>
--
“Come to the edge, he said. They said: We are afraid. Come to the edge, he
said. They came. He pushed them and they flew.”
Guillaume Apollinaire quotes
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
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/model-glue?hl=en
