sounds like you want to rewrite gwt but using wicket model for handling markup instead of layout manages which is what gwt uses. it is probably much easier to write a library for gwt that implements the wicket markup model rather then the other way around...
-igor On Fri, Mar 5, 2010 at 2: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? > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
