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]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
