While I don't personally like the proposal (only meaning I'm not likely to use it unless I see a really great usecase for it)... You may look at using DWR to help you with some of that stuff. It allows you to make service methods available directly in JavaScript, for example.
-- Jeremy Thomerson http://www.wickettraining.com On Fri, Mar 5, 2010 at 4:23 AM, Vladimir Kovalyuk <koval...@gmail.com>wrote: > Some thought ... > > Last week I thought a bit about reacting on events without client-server > round-trip and without having to write JS. I had an idea - to write event > handlers as methods and annotate them with special annotation > @ClientSideEvent. Then feeding the class to the Java-JS compiler we would > obtain the JS we need to embed into the page. And something similar about > component model - properties annotated with @ClientSide would be available > to client-side events (and marshalled to the server as path scoped cookies > for instance). > To start experiment with that I downloaded GWT 2 devkit and had a look to > their compiler. Unfortunately it is not capable to compile single class > into > JS. It requires a bunch of configuration and core infrastructure and it > always generates HTML. The class of your interest would be the inlined JS > script within the generated HTML. That does not suits. And BTW gwt compiler > is slow as hell (minutes!!!), how people are happy developing GWT > applications? > > Then I realized what I'm looking for - the decompiler from .class file to > .js file with some filtering capabilities. > Having such a tool it becomes possible to add dynamically decompiled .js > resources to the components (js accessible via URLs) and write client-side > state in Java, along with server-side state. All we would need to implement > are client side context and client-state marshalling. > > Although it seems doable I'm afraid it may be extremely expensive to > develop > and support such a tool. And it would require some changes in Wicket > rendering process (opeate with attributes in dom manner instead of handling > onComponent rendering event). > > The next generation of HTML/JS would evolve towards client programming > capabilities. I like Wicket for its full freedom of HTML (contrary to GWT) > and I would like to use similar model when programming rich web client > applications. And it is less about the Wicket way of splitting html and > java. It is more about binding to dynamically loadable data with any deep > of > structure displayed on users demand. The GWT way would require to program > it > in any way when Wicket does it transparently. Another story is > authorization > that can be done transparently. But web development evolves and client side > programming becomes more and more demanded. I tried to think about how > technically we could use the best of both worlds. > > What do you think about all that? >
