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
Hans: I hadn't looked at that project, thanks for mentioning it.
Thank you all for your input.
It seems the only viable solution is to keep track of Futures in another
scope than the relevant components so I'll go with that.
On 24/07/2011 1:21 AM, Rodolfo Hansen wrote:
Have you thought
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
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
Perhaps a transient Future would work for you after all. If the user
navigates away the Page is serialized and the Future is thrown away.
If you do put futures in a Map, perhaps in the Session, I'd wrap that
in an AbstractReadonlyModelFuture. Then you could use have a
MapInteger,
Thanks for your answers Scott.
I thought Wicket could essentially serialize a page any time it sees
fit. Is that the case? If so, that would mean that even if the page
containing the Future reference is still open in the browser window, the
Future could be thrown away. Wouldn't that be a
Have you thought about keeping your future in another scope? a conversation
scope for example, or delegating it to the application / session ?
On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet
ber...@step.polymtl.ca wrote:
Thanks for your answers Scott.
I thought Wicket could
