Client side events in Wicket, what do you think about that?
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?
Re: Client side events in Wicket, what do you think about that?
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.comwrote: 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?
Re: Client side events in Wicket, what do you think about that?
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
Re: Client side events in Wicket, what do you think about that?
Hi, 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... Like this http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html? script within the generated HTML. That does not suits. And BTW gwt compiler is slow as hell (minutes!!!), We have compile times from 10 minutes up to over an hour. No kidding. how people are happy developing GWT applications? Definitively spoils the fun. Especially because in our experience, though GWT has the promise of write once for all browsers, you still need to do quite a bit of testing and tweaking to make sure everything looks good in different browsers. Also not very helpful is the fact that the Google Eclipse plugin uses the jars copied to a war/libs directory rather than the class path you define for your project, which cost us a lot of time because we have our projects broken up in smaller pieces (dependent projects), and every little change we have in one of the dependent libs means having to create a build for them, and then copying them to the war/libs dir. Hopefully this will be fixed some day. And then there is that if you don't optimize, you easily end up with over a MB initial download (just a medium sized application). Oh, and I never would've guessed how much we depend on introspection to take the plumbing code out until you have to do without as in GWT. Anyway, it's not all bad. The improvements for 2.0, including UiBinder, look good, and the code we're ending up with is, though more bloated than with Wicket, quite neat (good separation of concerns, testable, componentized, etc). I feel we took a substantial hit in developer productivity using GWT for our new projects rather than Wicket, and I would probably pick Wicket again for my own projects, but compared to the alternatives out there, GWT is still a pretty good framework, where the larger the scale (development wise) of your project, the larger the pay off is. 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. Yeah, another thing I miss is lazy-ness... but that'd be hard to reproduce when you would move from a request/ response model to JS driven. 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? Sounds to me like enough ideas to base a new framework on ;-) Personally I think that Wicket should keep focussed on the programming model we have now. Drastically changing that just means building another framework, and we can learn from other frameworks that that's just not a very good idea. Also, I wouldn't really have an idea how to implement this without basically copying GWT, which is probably hard to beat at it's own game. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
