Did you already take a look at wicketstuff-progressbar?

Regards
Hans


Am 23.07.11 17:02 schrieb "Bertrand Guay-Paquet" unter
<ber...@step.polymtl.ca>:

> I haven't actually done it yet, but the 3 steps you list are what I have
> in mind.
> 
> After these, I plan to use a javascript timer that polls the status of
> the request and updates a label (or icon). That ajax behavior would be
> the one polling the Future.
> 
> What I can't wrap my head around is this: the ajax behavior can't
> directly hold a reference to the Future because it can be serialized
> with the page. On the other hand, if I store the Future in a map
> somewhere and keep a serializable handle in the behavior, there is a
> possibility that the user will navigate to another page before get() is
> called on the Future. To avoid running out of memory, this means that I
> would need to have a daemon that periodically nulls stale Futures from
> the map so they can be garbage collected.
> 
> This kind of operation (submit + polling asynchronous result) seems
> rather common so I'm sure there's some (easy) way to handle it...
> 
> On 23/07/2011 9:14 AM, Scott Swank wrote:
>> What does your workflow look like?
>> 
>> 1. submit form (or ajax event)
>> 2. create Future
>> 3. return response page (or ajax response)
>> 
>> Now who checks the Future and what sort of UI result occurs?
>> 
>> Scott
>> 
>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>> <ber...@step.polymtl.ca>  wrote:
>>> Hello,
>>> 
>>> I can't find the correct way to handle java.util.concurrent.Future instances
>>> returned from asynchronous methods in Wicket. This interface does not extend
>>> Serializable so its instances can't be stored in components or pages. So
>>> what do you do with them?
>>> 
>>> Do you store them in a map in the application and keep a handle (e.g. an
>>> int) in the Wicket component?
>>> 
>>> I saw code on a github repository that implemented an ajax timer behavior
>>> that keeps a reference to a Future in a transient field to update a status.
>>> However, I can't understand how that would work. Wouldn't the transient
>>> field be nulled out if the behavior is serialized with the page and then
>>> deserialized?
>>> 
>>> Essentially, my question is: what is the standard way to handle Futures in
>>> Wicket that run longer than the page rendering? (like processing an order or
>>> sending emails)
>>> 
>>> I hope I'm not missing something obvious, but that might be the case...
>>> 
>>> Regards,
>>> Bertrand
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>> 
>>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to