On 20 sep. 2011, at 19:12, Juliano Viana <[email protected]> wrote:
> Hi, > > I have been following this discussion and I think its not fair to call > Wicket Ajax support broken. > I started using Wicket back in 2007, and the environment then was: > > - Support for IE 6 was a must. > - JavaScript on the browser was still slow and unreliable > - The applications where designed to work mostly with standard HTTP > request/replies, with only some specific functionalities being implemented > in Ajax. > > Since then the web has evolved a lot - IE 6 is dead (or dying), Google > Chrome raised the bar for the JavaScript engines and most modern browsers > now support WebSockets for low latency communications. We are now at the > point where some people are deciding not to use a web framework at all, and > rely instead on JavaScript plus RESTful web services (Google Plus is an > example of such an architecture). > > Wicket is still very good at what it does, specially considering the > environment in which it evolved. I personally dont think the API is an > issue - every API is a compromise and once you learn to live within its > limitations there is very little you can't do with Wicket Ajax one way or > another. > > The issue I see is: there is a lot of opportunity for making applications a > lot more interactive by moving processing to the browser. GWT does that by > compiling Java into JavaScript, but my latest experiences with JavaScript > have convinced me that this step is probably unnecessary - you can be pretty > confident that once you use a framework like JQuery your code will run > unmodified in the major web browsers. The only thing that is not so easy to > do is to interact with the server-side state. > > This is where I believe improvements can be made - enabling JavaScript to > interact easily with Wicket models and listeners. This would make it > easier to write more compelling user interfaces by leveraging current and > future JS frameworks while preserving the Wicket component and model > structure, which is in my oppinion Wicket's strongest point. > Hear, hear! With the server-side events now in place, would the next step be to expose them to the client? I think this would open up some nice possibilities where wicket ajax acts as the event hub. One thing that i've run into a few times was the need to hook an ajax call. I've needed to put in synchronous calls. It would be a lot better to (async) execute them before the original call. (restrictions such as skipping the render phase would be acceptable) Continuing the theme, server-push of updates would be nice-to-have imo. I don't know if it can/should be integrated with component rendering though. Another thing is splitting the action and render phase further. I've been pretty satisfied with separate action, (external) event processing and render phases. Cheers, Frank > Regards, > - Juliano.
