i did not say it was a bad idea to embed js components, i said it was a bad idea to try and build a gwt-like fat-client using wicket. for that there is gwt.
-igor On Wed, Apr 29, 2009 at 10:47 PM, Vladimir K <koval...@gmail.com> wrote: > > Igor, I believe it is not so bad idea to embed third-party JS components with > ease (those who are capable to wrap existing div tag). > > 1. Wicket applications can be leveraged by many well designed and tested JS > components > 2. It reduces hardware requirements and imroves scalability due to smaller > number of client-server roundtrips > 3. There are the cases where it is better to design component is JS instead > of Java, for instance imagine full calendar component (like MS outlook has), > dynamic charts (including Gantt), rich text editor and so on. Even any > drill-down component (menu, panel) is better to design in JS. > > Probably wicket should be capable of transferring js-component's client > state to backing server-side component when handling the client event. > Creating a hidden text input and serializing js-component state to it before > submit will work. Just for synchronization. Concerning events it seems we > just can use exising behaviors. > > I believe wicket ui in most cases is as fast as ajaxy js ui because in both > cases we have to exchange some packages of data and access the database. And > there should be the cases where wicket is faster because it can just apply > innerHtml. JS has to parse the response and do something with dom. > But there are the cases like tab control as mentioned, where we don't need > server roundtrip to switch tabs. From the other hand we probably just need > to optimize existing AjaxTabbedPanel to allow the settings on tab > (ajax/static). Depending on this setting the appropriate links will be > rendered on the tab captions. > > Concerning GWT ... just have a look at response times of Compiere 3.0 on > latest Google Chrome. On my 2.4Ghz desktop it takes about 7 seconds between > click on radio-button and see that selection is changed. GWT is out of the > scope. > > > igor.vaynberg wrote: >> >> dont try to make wicket into gwt. if you want a fat client then use >> gwt, if you want a server-side app then use wicket. >> >> -igor >> >> On Wed, Apr 29, 2009 at 8:06 AM, kan <kan....@gmail.com> wrote: >>> Is there any easy way to make wicket applications like GWT? I mean to >>> make a "heavy client side", so it will allow easy manage data >>> pre-loading and requests (AJAX too) caching. The aim is to minimize >>> amount of web-server requests. >>> Say, I have several tabs on a page. Some tabs should have all data >>> pre-loaded and switched immediately (no requests to server). Some tabs >>> are "big", so they do an AJAX request for data, but only if a tab is >>> opened first time. >>> >>> -- >>> WBR, kan. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > > -- > View this message in context: > http://www.nabble.com/GWT-like-tp23299279p23310287.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
