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] > >
