Re: Proposal: the browser as a desktop client
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]
Re: Proposal: the browser as a desktop client
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]
Re: Proposal: the browser as a desktop client
so write a prototype and present it to the community. we are all eyes. -igor On Thu, Oct 23, 2008 at 2: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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: the browser as a desktop client
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]
Proposal: the browser as a desktop client
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]
Re: Proposal: the browser as a desktop client
I just to clarify one point. You would still have three types of components: HTML CSS Java You would still be binding the Java code against HTML IDs (clean separation of concerns). The only thing that would change is where the Java code executes. -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111247.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]
