We use the interceptor for interrogating a legacy database where we have no control over the execution or timing of the query.
We basically have an API we call and then wait in hope. I have to say that I've found the interceptor to be inconsistent at best. For example we have some queries that are actually quite quick but the interceptor insists on doing at least one page refresh before returning a result. We've tried tweaking all the setting with absolutely no joy. On the last project, we actually implemented an ajax solution which was far more elegant result. Z. On 10/12/10 3:11 AM, "stanl...@gmail.com" <stanl...@gmail.com> wrote: >Does anyone actually use this interceptor? I have a team asking me about >it's use in production and how this solution would compare to a jQuery >solution. I played around with it lst night and am skeptical about it. >For >one thing, the documentation says > >"The ExecuteAndWaitInterceptor is great for running long-lived actions in >the background while showing the user a nice progress meter. This also >prevents the HTTP request from timing out when the action takes more than >5 >or 10 minutes." > >and a request like that would get me fired! > >Peace, >Scott --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
