Hi! >> Wicket (View) <-> Facade <-> (Model, Controller) > > Wicket (View) <-> Controller -> Facade (using interface IModel) + direct > model access -> Model (Data)
No. If contorller is touched by Wicket, it spoils the state. I know your proposal works in simple situations, but when you have lots of players, items and bolts, the problem is that we find ourselves with multiple "actors" from different request cycles (different serialized copy). So I see that only solution is to push all meaningful parts behind the facade so all wicket sees is a single instance of facede and controller. > So what exactly is the problem? > > If you don't like serialization you basically use something > like LoadableDetachableModel. Well.. I need to keep the "selection" somewhere. And if I have a hierarchical structure the first idea is to keep the "selection" instance inside wicket. But whoa when you need to do something with that "selection" after it has become stale. Anyways, the use case is quite complex to explain in short. Think like if you were implementing the Rubic Cube with wicket... the dependencies get quite complex. > Serialization is needed to persist state across request over a > stateless protocol like HTTP. It's not there to bully our users :-) Exactly, but it is very error prone to try to keep track of the instances. It is simply easier to push all such logic out of wicket, to behind the facade. > If you can't serialize you need to restore state on your own using > for example LoadableDetachableModel. Well.. that would be a stateless application ;) ** Martin > >> >> My 2cents ;) >> > > 4 cent now :-) > > If you need help you are always welcome to ask! > > Best regards > Peter > >> ** >> Martin >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
