rather than have Wicket/GWT sincerely i envision a wicket contrib project that can help us generate javascript on the fly from pure java code within wicket for common and simple client side behavior.
Wicket ajax is very solid but believe me, Javascript has come to stay for a while. So I think a flexible java to javascript integration will not be a bad idea. cuz not all behaviors are going to be ajax based. Some behaviors just need to happen within the browser without getting back to the server each time. some are already built into the framework like CheckBox.wantOnChangeNotification but they all somehow leverage ajax which is why i could not use Echo because i dont want to have to hit my server because my game sprite has to hit the server to move from point A (34,90) to point B(34,91). the world is still short of bandwidth But i look at a common base and generic API specification and interface for stuffs that is pure @runtAtClient stuffs. Any javascript framework can be used but they must confirm to this API DND, visibility, sound, client side validation, simple animation, fading, shadow, warning popups and a host of them. maybe a provider pattern like I can use Hibernate or Toplink for JPA, with this API , I can take any Dojo, Scriptaculous or Mootools contrib that complies to this API and use then. I suggest an interface that is also compatible with IBehavior. There is also a factory that takes this interface and compiles the java code into javascript , dynamically wraps the script around the appropriate component somehow and then you wont need to even care about javascript for many basic client based activities. On 12/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On Dec 11, 2007 2:15 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > > I've scoured the internet to figure out how to integrate a GWT app > inside a > > Wicket App. I'm not getting very good results. I also checked the > mailing > > archives and didn't really find any technical advice on how to do this. > > What specific problems have you encountered? My understanding is that > GWT runs much like an applet, and client server communication is done > using services that can be implemented in various ways. I don't think > GWT and Wicket should bite each other much here. > > > First, I noticed a lot of the attitude towards GWT/Wicket is that you > > usually want to choose one or the other. I disagree. In fact, I think > > comparing GWT to Wicket is comparing apples and oranges. GWT is a > Toolkit, > > and Wicket is a Framework. They both do different things and they're > both > > very good at what they do. Therefore, it's worthwhile to have GWT > > integration in wicket. > > I guess most people just don't want to use two technologies with an > overlap. But no-one of the core team at least is against doing it. It > would be fun to hear from people who did that with success. I don't > see why it couldn't be done (but then again... I never actually > tried). > > > That being said, I've also inferred from most of the Wicket + GWT > > conversations that the Wicket developers are trying to add some huge > > functionality to Wicket to allow you to place the a GWT app from your > > WebPage classes. That may come in handy, but I'm not so sure that it's > > necessary. I think the client side code that GWT requires could easily > be > > added by hardcoding it in the markup and that would be good enough for > most > > (myself included). The part that's tricky to me is this section: > > > http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.Developer > > Guide.RemoteProcedureCalls.html > > Yeah. Maybe we/ Wicket's users want to do things to neat/ generic. :-) > > > Specifically, if you scroll down a little to the image, how do you get > the > > right side to integrate with Wicket? As you can see, GWT uses a > > RemoteServiceServlet if you want your GWT app to communicate with the > > server. But the wicket philosophy seems like it tries to hide Servlets > from > > the user. So, in short, can anyone advise me on how to integrate a GWT > app > > with Wicket? > > I don't have much advise other then try to keep it simple and if it > works, it works. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Aladejebi Ayodeji A., DabarObjects Solutions Phone: +234 9 481 7 156 Mobile: +234 803 589 1780 Email: [EMAIL PROTECTED] Web: www.dabarobjects.com Blog: blog.dabarobjects.com Participate, Collaborate, Innovate Join Community: http://www.cowblock.net/ Get A Free Blog: http://blogs.cowblock.net/
