Wicket Ajax direction and roadmap regarding push-like updates
Please correct me if i'm wrong but it looks like 1.5 and 1.6 wicket will
continue to use behaviors to work with ajax events driven by user events or
timers. In the real world a lot of my ajax needs occur when i need to push
back page state changes and don't want to write 100 lines of code with
custom javascript just to do something that could be provided by the API.
Hopefully I'm just ignorant of the existing elegant solution.
onClick(AjaxRequestTarget target){
//disable some controls
...
doWorkThatTakesSomeTime();
// update some label with current status
...
doSomeMoreWork();
// append results to an unordered list
// update labels with final results and enable controls
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4351890.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
Re: Wicket Ajax direction and roadmap regarding push-like updates
Hi,
Correct me if I'm wrong but not many of the browsers (IE, I look at
you) support modern technologies like WebSocket.
Correct me if I'm wrong but not many web servers support WebSocket
too, only Jetty and Glassfish support it.
So we cannot add support for some browsers and/or some server and ignore others.
Additionally WebSocket connection is not processed by servlet filters
and this requires some tricks to be able to use Wicket Application.
Session and Page objects.
Currently the best you can use is wicketstuff-push and/or Atmosphere
which fallback to not-so-pushy technologies when they are not
supported by the browser/server.
On Thu, Feb 2, 2012 at 6:05 PM, pkc wrote:
> Please correct me if i'm wrong but it looks like 1.5 and 1.6 wicket will
> continue to use behaviors to work with ajax events driven by user events or
> timers. In the real world a lot of my ajax needs occur when i need to push
> back page state changes and don't want to write 100 lines of code with
> custom javascript just to do something that could be provided by the API.
> Hopefully I'm just ignorant of the existing elegant solution.
>
> onClick(AjaxRequestTarget target){
> //disable some controls
> ...
>
> doWorkThatTakesSomeTime();
>
> // update some label with current status
> ...
>
> doSomeMoreWork();
>
> // append results to an unordered list
>
> // update labels with final results and enable controls
> }
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4351890.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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Ajax direction and roadmap regarding push-like updates
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
Re: Wicket Ajax direction and roadmap regarding push-like updates
Hi, On Thu, Feb 2, 2012 at 8:21 PM, pkc wrote: > 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. > I'm afraid this is not possible with current version of HTTP protocol. Sevrlet containers use a Thread for each request/response, so you cannot block the user code (as you said "to make it synchronous for the user") and in the same time to write back in the web response, close the connection and start a new connection, ... Even with Servlet 3.0 this is not possible. There you can suspend request/response, do some heavy calculation and when ready resume the request/response and write the result. As I suggested: take a look at wicketstuff-push. > > > > > -- > 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 > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Ajax direction and roadmap regarding push-like updates
It is a tricky topic because what can be done from the wicket api level doesn't have to use true push for the default implementation. I don't like the push solutions out there. Ice-push looked promising because of the hype but after issues with memory leaks and overly complicated requirements, I switched to jQuery and two rest-style request handlers and it was so simple (one url for status updates and one for the request that is taking a long time). I don't know why there is resistance to a default wicket push interface that works with jquery or pure ajax to provide a default implementation. I bet most wicket developers would welcome a simple solution like this. Especially if the wicket team made the interface flexible enough to plugin alternate push solutions as they become standard. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4362477.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
Re: Wicket Ajax direction and roadmap regarding push-like updates
Just to mention that I'm personally more than happy with Atmosphere. There's a little work coming in order to support lots of Comet channels (it will be contributed back when it's done) but for a simple use with two or three channels it works like a charm. Plus there's a working Wicket example available in the official distro. And it's unit testable. Or at least, it doesn't prevent you to unit-test the regular Wicket code, not like wicket-push for instance, that I gave up because it prevented me to unit test my regular (non-Comet) code. You won't have a perfect for all, no JavaScript solution but it's pretty well integrated with our favorite framework and it handles very well the different clients and servers solutions. Plus the support of WebSocket is coming and I know from the author that the Atmosphere guy and the Tomcat guys are working together for a forth-coming WebSocket support in this nice servlet engine. Regards, Pierre On Mon, Feb 6, 2012 at 8:33 PM, pkc wrote: > It is a tricky topic because what can be done from the wicket api level > doesn't have to use true push for the default implementation. I don't like > the push solutions out there. Ice-push looked promising because of the > hype > but after issues with memory leaks and overly complicated requirements, I > switched to jQuery and two rest-style request handlers and it was so simple > (one url for status updates and one for the request that is taking a long > time). I don't know why there is resistance to a default wicket push > interface that works with jquery or pure ajax to provide a default > implementation. I bet most wicket developers would welcome a simple > solution like this. Especially if the wicket team made the interface > flexible enough to plugin alternate push solutions as they become standard. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4362477.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 > > -- Si tu penses que la violence ne résout rien, c'est que tu n'as pas tapé assez fort.
Re: Wicket Ajax direction and roadmap regarding push-like updates
i am a bit curious,what version were you using of wicket and wickestuff push and how exactly push didnt let you unit test your code? On Tue, Feb 7, 2012 at 1:37 AM, Pierre Goupil wrote: > Just to mention that I'm personally more than happy with Atmosphere. > There's a little work coming in order to support lots of Comet channels (it > will be contributed back when it's done) but for a simple use with two or > three channels it works like a charm. Plus there's a working Wicket example > available in the official distro. And it's unit testable. Or at least, it > doesn't prevent you to unit-test the regular Wicket code, not like > wicket-push for instance, that I gave up because it prevented me to unit > test my regular (non-Comet) code. > > You won't have a perfect for all, no JavaScript solution but it's pretty > well integrated with our favorite framework and it handles very well the > different clients and servers solutions. Plus the support of WebSocket is > coming and I know from the author that the Atmosphere guy and the Tomcat > guys are working together for a forth-coming WebSocket support in this nice > servlet engine. > > Regards, > > Pierre > > > > On Mon, Feb 6, 2012 at 8:33 PM, pkc wrote: > >> It is a tricky topic because what can be done from the wicket api level >> doesn't have to use true push for the default implementation. I don't like >> the push solutions out there. Ice-push looked promising because of the >> hype >> but after issues with memory leaks and overly complicated requirements, I >> switched to jQuery and two rest-style request handlers and it was so simple >> (one url for status updates and one for the request that is taking a long >> time). I don't know why there is resistance to a default wicket push >> interface that works with jquery or pure ajax to provide a default >> implementation. I bet most wicket developers would welcome a simple >> solution like this. Especially if the wicket team made the interface >> flexible enough to plugin alternate push solutions as they become standard. >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4362477.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 >> >> > > > -- > Si tu penses que la violence ne résout rien, c'est que tu n'as pas tapé > assez fort. -- thank you, regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Ajax direction and roadmap regarding push-like updates
Sounds promising. As a wicket user, I would like to see a very tight integration of a push API in wicket-core. It seems most solutions are overly complicated and it would be nice to have a simple API that just let you add listeners or set up channels, then fire off a job and wicket core would take care of making sure the background updates were coordinated with normal page events and state. Similar to the Atmosphere solution, ideally there would be a lightweight, default/fallback implementation that doesn't involve adding a bunch of dependencies to wicket core. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4370083.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
Re: Wicket Ajax direction and roadmap regarding push-like updates
I was using wicketstuff-push with Wicket 1.4. And it used to prevent me from unit-testing because of NPEs in the push code, IIRC. Regards, Pierre Goupil On Wed, Feb 8, 2012 at 5:58 PM, pkc wrote: > Sounds promising. As a wicket user, I would like to see a very tight > integration of a push API in wicket-core. It seems most solutions are > overly complicated and it would be nice to have a simple API that just let > you add listeners or set up channels, then fire off a job and wicket core > would take care of making sure the background updates were coordinated with > normal page events and state. Similar to the Atmosphere solution, ideally > there would be a lightweight, default/fallback implementation that doesn't > involve adding a bunch of dependencies to wicket core. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-Ajax-direction-and-roadmap-regarding-push-like-updates-tp4351890p4370083.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 > > -- Si tu penses que la violence ne résout rien, c'est que tu n'as pas tapé assez fort.
