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]
