Hey:
I know one of the things people find annoying about working with Tiles is the mysterious "blank screen".
When an exception is thrown while the tile is being evaluated, Tiles throws a JspException, and the Struts ExceptionHandler (if you're using it) tries to forward to the registered path. This fails because the HTTP response has already been committed.
I'm having decent results with a local subclass of the ExceptionHandler which only returns an ActionForward if the response has not been committed, and then, if the registered path begins with "/", it attempts to do a requestDispatcher.include(req, resp) instead.
This is working for me now, because the artists haven't gotten to making the error page look good enough for production -- but they will, and at that point it will look dorky nested in the tile-set. Besides, it doesn't seem like a solution suitable for putting in the Struts core -- but it seems like its close.
I propose coming up with a configuration syntax for helping the ExceptionHandler do something when the response is committed. Perhaps just an alternate property to "path", like "committedPath", which would explicitly be used. The rest of the behavior would be as is, and in fact many people who use Tiles would just make "path" point to a tile-set which wrapped their "committedPath" tile in a typical design for their site.
Am I making sense? Is this a good idea? Is "committedPath" the best name for the config property for the ExceptionConfig object?
(Would we still want to consider implementing my current strategy as a fallback if "committedPath" is not defined?)
I think this is one which will make a lot of people happy if we figure it out!
Joe
-- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
