Thanks for the reply. The direction I'm wondering about is kind of like chained ajax requests and responses. At the API level you would update some controls in the onClick(), then tell wicket to return the updated ajax targets by calling some API method that would block until the web browser sent the next request saying it got the response and is ready to continue. So Wicket would make it a synchronous method for the developer but behind the scenes, it would be sending ajax responses and telling the web page to immediately make another request to continue the wicket server-side method.
The first release could make some assumptions like the socket would just block until the code is finished for each section of code that takes a while. Then it could be refined as browsers and java servers better support push technology. Couldn't this be added to the core API and provide an interface for different implementations? I'm no expert but this is on my wish list. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4352332.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
