execAndWait Interceptor

[st...@gmail.com]

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

Re: execAndWait Interceptor

[Dave Newton <da...@gmail.com>]

On Thu, Dec 9, 2010 at 11:27 AM, wrote:

> I thought about that Dave, but isn't reporting an exception to the rule?
>

So what if it is? Long-running requests still exist (or may, depending on
architecture).


> Also, should a web framework try to play the role of a reporting solution?
>

As the front end? Sure, why not? Browsers are what people have.

I don't know what kind of data you deal with, but when you're looking at
ad-hoc reports across gigs of data, it may take awhile to generate a report,
regardless of the underlying technology used to *create* the report.

d.

Re: execAndWait Interceptor

[st...@gmail.com]

I thought about that Dave, but isn't reporting an exception to the rule?
Also, should a web framework try to play the role of a reporting solution?
I'm trying to get a handle on roles and responsibilities more than anything
else.  Very few web developers like the Swiss Army Knife approach on account
of it's complexity, weight, dependencies, and chance of hacking off a digit
during use.  The discussions we are having around here this week are more
along the lines of clean architecture than is it something Struts could do?

On Thu, Dec 9, 2010 at 10:18 AM, Dave Newton <da...@gmail.com> wrote:

> But some requests just take that long, reporting in particular. I'm not
> sure
> what that has to do with execAndWait in particular, though... I'd rather do
> something Ajaxy myself, but that's kind of a separate issue.
>
> Dave
>
> On Thu, Dec 9, 2010 at 11:11 AM, <st...@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
> >
>

Re: execAndWait Interceptor

[Dave Newton <da...@gmail.com>]

But some requests just take that long, reporting in particular. I'm not sure
what that has to do with execAndWait in particular, though... I'd rather do
something Ajaxy myself, but that's kind of a separate issue.

Dave

On Thu, Dec 9, 2010 at 11:11 AM, <st...@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
>

Re: execAndWait Interceptor

[Dale Newfield <da...@newfield.org>]

On Dec 9, 2010, at 11:11 AM, stanlick@gmail.com wrote:
> Does anyone actually use this interceptor?

Extensively.

Any system that contains large amounts of data can have valid reasons for needing this, and not just for reporting.

-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: execAndWait Interceptor

[Zoran Avtarovski <zo...@sparecreative.com>]

Sorry about the delayed response. I have been busy with xmas crap (ba
humbug).

The way we implement an ajax solution is to create a new thread, with a flag
stored in the session and poll the server using a jquery ajax call every 10
seconds. The ajax call returns a json response which has the flag value as
its first item and then relevant data if the process is complete.

The beauty of this is we have no page refreshes and when the process is
complete use the ajax response to either display the info or a link to the
report.

Z.


On 14/12/10 7:06 PM, "RogerV" <ro...@googlemail.com> wrote:

> 
> 
> 
> Sparecreative wrote:
>> 
>> 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.
>> 
> 
> Are there any pointers or code samples available to show how to implement an
> ajax exec & wait?
> 
> Regards



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: execAndWait Interceptor

[RogerV <ro...@googlemail.com>]

Sparecreative wrote:
> 
> 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.
> 

Are there any pointers or code samples available to show how to implement an
ajax exec & wait?

Regards

-- 
View this message in context: http://old.nabble.com/execAndWait-Interceptor-tp30418047p30452640.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: execAndWait Interceptor

[Zoran Avtarovski <zo...@sparecreative.com>]

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, "stanlick@gmail.com" <st...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org