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