But the idea to export partly functions and so have a bit longer load time but less roundtrips seems quite interesting... could be the base idea to start a new wicket 2.0 *screams it and runs away*...
> -----Ursprüngliche Nachricht----- > Von: Matej Knopp [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 4. April 2007 12:55 > An: [email protected] > Betreff: Re: Wicket + java->javascript compiler? > > 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 > > > > >
