> That's true, but still there may be some use cases where the component > tree is not changed but the "application wide" state of some domain > object is changing that triggers the ajax update of a component.
Second thought: maybe wicket is just not the right fit for such use cases (fixed component tree, no real interaction with the user) and so this framework should not be used where server side state storing is thought to be too expensive... I held a presentation on Wednesday about wicket in the local (Budapest) Java User Meeting, and most of the questions were related to server side session storing. I felt it really impressed some people how wicket implicitly makes sure there is a roundtrip on each ajax event to the server so there will be no differences between the client and the state stored on the server... j ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
