Is the browser not a client in Wicket? You have to slice things differently.
I agree that using GWT will mean more thought has to go into interaction with the middle tier but that just means some of your code stays on the server in some simple facade. It wouldn't be one of my worries in using GWT. In Wicket or GWT when the user clicks something you have to marshall the same data for both. If Wicket uses a remote middle tier (including DB) very similar issues will crop up. We have found the need to make some of our model serializable to make working with Wicket nice. Obviously lots of pros and cons for both that have not been mentioned so far. igor.vaynberg wrote: > > how about another tiny limitation which is the programming model. gwt is > essentially client+server so you cannot use hibernate lazy loading, you > cannot use data locality to your advantage either. you have to serialize > all > your data so you can only use simple objects to communicate between your > server and ui. > > but those are not at all important are they? > > -igor > > > On 9/25/07, Sam Hough <[EMAIL PROTECTED]> wrote: >> >> >> Another big GWT limitation is that you have a very small subset of java >> runtime to write your UI in. Lots of your favourite things are probably >> missing. >> -- >> View this message in context: >> http://www.nabble.com/Questions-about-GWT%2C-JSF-and-Wicket-tf4514338.html#a12879789 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Questions-about-GWT%2C-JSF-and-Wicket-tf4514338.html#a12881704 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
