But wicket is a framework that manages server side state.
-Matej On 4/4/07, Neeme Praks <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote: > > I don't see the big picture of how this would fit into Wicket though. > What would the concrete goals be? I can imagine delivering a more > strongly typed version of the wicket-ajax.js file, which is something > we talked about a little bit a while ago but is something we haven't > really found time for. Indeed, that could be one of the possible usages, but not the one that I had in mind. > But your proposal goes much further than that, > and implies that arbitrary parts of Wicket components/ behaviors can > be compiled to Javascript? > > Maybe a good start is to provide a good use case with an example of > how it would be used? On wicket page, there is an Ajax Counter example, I'll use that as a reference (http://incubator.apache.org/wicket/exampleajaxcounter.html). When you look at that example, it is quite obvious that Wicket AJAX support is geared towards the use-case of: 1. render some DOM on the client 2. in response to some UI event (e.g. clicking a link), send a background request to server that will update the server-side model and will result in a list of client-side components to update (in reality, a list of DOM elements) and a list of javascript snippets to evaluate in the client. 3. client side javascript handles this response and updates components on the client side. What I'm trying to achieve here, is to remove the need for server round-trip at step 2 - if we could compile the model to run at the client, we do not need to visit the server so often, resulting in much faster and more responsive UIs. And, at the same time, if the client does not support AJAX, we can fall back gracefully to run the model entirely on the server. Achieving this will of course take some effort from the developer. There are security considerations to running things in the client so the developer has to be fully aware that this code might run in the client and as a result, cannot be fully trusted. This means that developer has to take explicit steps to mark what parts of his code can be run on the client and what should be server-side only. And we need some sort of RPC mechanism for crossing the client-side to server-side boundary, I'm not sure if Wicket currently supports such functionality. Should be fairly easy to add it though, as with java2script we have reflection support at both sides, making JSON-RPC-java a good candidate for this. As for the marking what code can be run at the client-side, the first three (obvious) options that came to my mind are: annotations, configuration and marker interfaces. I hope this somewhat cleared up the confusion about the use-case I have in mind. Waiting for further comments, questions and ideas, Neeme
