wicket-push also does update queueing.
Regards,
Seb
On 12.11.2010 20:47, Igor Vaynberg wrote:
not a bad idea. we already have a concept of "channels", but right now
they can only queue or drop requests. with some work it should be
possible to add an "aggregate" mode and process multiple callbacks
within the same request. please file a jira issue.
-igor
On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong<[email protected]> wrote:
EXT-JS does a nice queueing model where you can set a queue timer (say
100ms) and any AJAX requests get bundled up into a single package that
goes across the wire at once, returning and then being sent back to
their callers.
This lets a page update many components at once in what appears to be
real-time without blocking.
Might be an interesting model for wicket at some point in the future.
Yes, I know, EST-JS is a client-side framework. I am only using it as
an example of how some stacks are resolving these sorts of issues.
John-
On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau<[email protected]> wrote:
AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it
wouldnt work very well for a chat-like scenario. I have set mine to 30
seconds and it works perfectly. Long polling would hold a request with
nothing to report back in most of the times.
regards.
On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg<[email protected]>wrote:
why would you need a request every few milliseconds. what is so urgent
about a notification that you cant poll every ten seconds?
what your long polling thread can do is access the page, render a part
of it, and send it back to the client - but, only when it has
something to say. which instead of many very quick requests to the
page is many very quick accesses to the page.
-igor
On Fri, Nov 12, 2010 at 9:13 AM, José Monzón<[email protected]> wrote:
AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests.
But if you try to do long polling with that (comet, retain the request
in the server as long as you can while there's nothing to send back)
you will see how your other ajax requests are queued and your page
freezes.
I've seen many people using AjaxSelfUpdatingTimerBehavior to replace
long poling. Performing very quick requests to the server (every few
millisecons). I believe that abusing AjaxSelfUpdatingTimerBehavior
leads you to scalability issues. Not to mention that the browser gets
choppy in slow computers.
On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau<[email protected]>
wrote:
I have implemented an application that alerts the user on various
events. I
created a notification's bar at the top of my page. This bar has a panel
on
which i added AjaxSelfUpdatingTimerBehavior. The Panel is available in
all
pages. whatever the page the use is, as long as the panel is rendered,
it
polls the server on regular intervals and displays notifications for
various
events - the facebook style. This is one of the features that has made
me
stick with wicket.
regards.
Josh
1.
http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html
On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt<
[email protected]> wrote:
On Fri, Nov 12, 2010 at 3:55 PM, José Monzón<[email protected]>
wrote:
I recently run into a problem that has make me consider whether
continuing using Wicket or not for a project. I hope guys you can
throw some light into it.
I need to create a web application that uses ajax to keep itself
udpated while still allows the user interact with it also using Ajax.
Imagine something as GMail, Documents, Facebook, Twitter, etc.
On this pages, is very common to have some ajax COMMET, long polling
or also known as inverse AJAX to keep the page updated. But that
doesn't prevent the user to click here and there and update the page
also using AJAX. They are independent XMLHttpRequest with a browser
can handle perfectly.
I was thinking about doing this on Wicket, but apparently it's
impossible by design:
https://issues.apache.org/jira/browse/WICKET-2437
Page objects aren't thread-safe and wicket will block any other
thread
(AJAX call) that tries to access the page while another request (for
instance our long poll) is there.
Have you ever find yourself into this kind of problem? What's the
workaround if any?
the comet-like functionality is useful for things like chatting, but
you wouldn't
need access to the page for that as you're unlikely to change the
component tree.
The alternative to long polling is, of course, regular polling. Queue
the events
and process them when a request is processed. Then you can access the
page,
update the component tree and rerender the relevant parts.
Maintaining the queue
is a bit tricky, as one has to make sure that it doesn't grow too
large and it must be
disposed of properly.
We've used this method to implement a single-page-application that
updates
exclusively with ajax. It's not in the facebook/google/... range, but
it works well
enough for our purposes.
cheers, Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Hippo
Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20
522
4466
USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100
• +1 (707) 773 4646
Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC
H2T 1S5 • +1 (514) 316 8966
www.onehippo.com • www.onehippo.org • [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
