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]
