Johan, I'm not saying you should move *everything* over to the client. I'm saying that most form manipulation can take place without querying the database, especially on a per-request basis. Adding rows and cell validation tend to rely on at most one database lookup (during the initial request). Even if you *do* need to query the database before carrying out some operation (I dare say this is a minority situation) you can issue a web service call to do just that. Wicket's current implementation assumes that by default form manipulation should take place on the server. I am saying that by default it should take place on the client. The same functionality is still possible, it's just your default that changes. And as I mentioned, this approach has many benefits besides performance.
Gili Johan Compagner wrote: > > because on the server the business logic runs > Its a complete different paradigm > > if thinks that are now done in onclick() or onsubmit() would run on the > client > what would be possible then? Currently many people just call DAO's there > (spring stuff and so on) > > johan > > > On Thu, Oct 23, 2008 at 11:40 PM, cowwoc <[EMAIL PROTECTED]> wrote: > >> >> GWT generates business logic, HTML and CSS from Java code; as opposed to >> letting you bind business logic written in Java against normal HTML >> files. >> It doesn't have a clean separation of concerns like Wicket. >> >> Ask yourself this, why does the client rely on the server to do dynamic >> form >> manipulation on its behalf? Is it because the server really cares about >> the >> intermediate form states or is it because we don't want to write this >> logic >> in Javascript? >> >> Gili >> >> >> Johan Compagner wrote: >> > >> > use GWT because thats the key difference between wicket and gwt >> > >> > I only see some things like validators that could be precompiled not th >> > complete webapp and all your current page/panel/component/html code >> > >> > >> > On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <[EMAIL PROTECTED]> >> wrote: >> > >> >> >> >> Hi, >> >> >> >> I'd like to propose we leverage existing Java to Javascript compilers >> to >> >> improve Wicket on a couple of fronts. If you think of the web browser >> as >> >> a >> >> desktop client involved in a client-server architecture then it >> becomes >> >> obvious that Wicket is currently asking the server to handle a lot of >> >> logic >> >> on behalf of the client. It does this because it's easier to develop >> in >> >> Java >> >> than in Javascript. In an ideal world, the server should only see HTML >> >> forms >> >> in two states: >> >> >> >> - their initial state (sent to the client) >> >> - their submitted state (merged into the database) >> >> >> >> The client would be able to communicate with web services in between >> to >> >> update the client-side state but most applications won't even need >> this. >> >> The >> >> vast majority of form manipulation (adding rows, data validation) can >> be >> >> handled completely on the client-end. >> >> >> >> I foresee the following benefits: >> >> >> >> - Vastly simplified logic: A lot of resources have been spent building >> >> the >> >> HTML parser and classes related to server-side form manipulation. All >> >> these >> >> are built in for free in JS. For example, interacting with HTML >> elements >> >> and >> >> IDs is far easier than in Java code. >> >> - Improved responsiveness for end-users >> >> - Improved server scalability >> >> - "Nice" URLs, both for humans and for web crawlers. This would also >> open >> >> up >> >> the door for RESTful implementations. >> >> >> >> This would be different from GWT. You would benefit from the >> modularity >> >> of >> >> Wicket, coding HTML and CSS in their native languages. The only >> >> difference >> >> is that you'd now be manipulating dynamic forms on the client-end >> instead >> >> of >> >> the server-end. >> >> >> >> Let me know what you think. >> >> >> >> Gili >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html >> >> 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/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html >> 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/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140645.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
