I've since added additional capabilities and committed it. To enable
it, add the 'debug' parameter to your querystring. Different values
give different results:
- 'xml' gives you an XML dump of the request, parameters, session,
context, and value stack
- 'console' gives you an AJAX-enabled OGNL console that lets you test
OGNL expressions on the live data. The context is also dumped to XML
and the original page is shown.
To test it, run the following commands with Java 5 as your default jdk:
- ant
- java -jar build/struts-action-2.0-dev.jar quickstart:starter
Then in your browser:
- http://localhost:8080/starter/helloMatrix.action
- http://localhost:8080/starter/helloMatrix.action?debug=xml
- http://localhost:8080/starter/helloMatrix.action?debug=console
This uses the great QuickStart tool that packages an auto-compiling
application server into the struts-action jar.
Gabe wrote:
Don,
Sounds interesting but I wonder if it can be expanded to be made more flexible:
1) Create an XML result type (is there one already?) and a global result of that type
that is the result that the interceptor forwards to if "debug=true". This XML
result type could (eventually or now) then be used to print XML for a variety of uses
(perhaps, such as creating DWR like javascript objects for AJAX calls or outputting SOAP
responses).
I'm not sure how you'd have a certain result fire based on a request
parameter. The only way I found was to use an interceptor, and have it
register a PreResultInterceptor so that I could do things after the
Action had executed, but before the result ran. If my "things" closed
the output stream, then obviously the next result couldn't do anything.
There is probably a cleaner way to do that.
2) have an optional parameter to this interceptor that allows you to change the
global result. Thus, you could write your own result that dealt with the debug
differently than xml.
That is a good idea. So you are saying we'd still have an interceptor?
How can an interceptor change the result from an action? It seems the
PreResultInterceptor only gets a copy of the result string, not able to
modify it. I like the idea of making it more pluggable, though.
3) I wouldn't use the parameter name 'debug' because it is generic and might be
used by applications for other things. We wouldn't want developers to have a
debug=true parameter used for other reasons and then suddenly everything is
printed out as XML (maybe printForDebug=true instead?)
Yeah, that is a good point. Perhaps the default is 'debug', but you can
change it by setting an interceptor parameter. FWIW, the version only
does things if debug equals 'xml', 'console', or 'command'.
As an aside, another thing to consider is whether the interceptor should be part of Struts or XWork. Since the interceptor itself doesn't really have a web specific scope, I would say that it really belongs as a contribution to XWork. (Or at least this is the way the relationship btw XWork and Webwork used to work).
It seems like it would work fine for XWork, but it requires access to
the response's output stream. I guess we could abstract all the non
response-writing code and put that in XWork. I'd be fine with that.
Thanks for the great feedback and ideas!
Don
Gabe
----- Original Message ----
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Friday, March 31, 2006 9:49:37 PM
Subject: [action2] Debugging interceptor for devMode
Sorry, forgot the [action2] tag...
Don Brown wrote:
I've created an interceptor that I've found invaluable for debugging.
When you append "debug=true" to the query string, this interceptor
hijacks the normal result and instead, dumps the parameters, context,
session, and value stack to the response as XML. Since most browsers
know how to handle XML, this is a great tool for getting a view at the
data behind the page. The interceptor only works when devMode is set to
true.
I'm putting this in as a ticket[1], because I'd like some feedback
first. It is my intention to put this interceptor into the default
stack. Since it only engages when devMode is enabled, it should be safe
and have little effect on production applications.
Don
[1] http://issues.apache.org/struts/browse/WW-1279
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
