Re: A lesson learned about wicket
> a simpler approach: > > https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ Maybe yeah, but in our situation our model/controller complexity is almost like a relational db, so it will reside completely in its own layer facaded by "entitymanager". Yeah, exactly what we are looking for. ** Martin > > -igor > > On Wed, Dec 14, 2011 at 12:12 AM, Martin Makundi > wrote: >> Hi! >> >> Today I have learned about a huge misconception I have had about wicket 1.4. >> >> I have actually been thinking that it is an MVC framework. >> >> But it is practically not. Why? Wicket's request cycle and >> serialization process makes effortless MVC design almost impossible. >> It seems like wicket is just an "MVC proxy", via IModels. >> >> Maybe it's just my mistake, but maybe it is also a design issue in >> wicket. Don't know yet. >> >> Nevertheless, I am trying out a new approach where model and wicket >> are more strictly decoupled: wicket will only render what is managed >> in a non-visual model that has a some sort of "facade" representation >> which can be iterated and rendered. >> >> So it will be: >> >> Wicket (View) <-> Facade <-> (Model, Controller) >> >> Until now I have been wronlgy assuming that wicket can manage the >> lifecycle of Model, View, Controller, but it truly becomes a mess with >> serialization issues and complex logic. >> >> My 2cents ;) >> >> ** >> 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
Re: A lesson learned about wicket
a simpler approach: https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ -igor On Wed, Dec 14, 2011 at 12:12 AM, Martin Makundi wrote: > Hi! > > Today I have learned about a huge misconception I have had about wicket 1.4. > > I have actually been thinking that it is an MVC framework. > > But it is practically not. Why? Wicket's request cycle and > serialization process makes effortless MVC design almost impossible. > It seems like wicket is just an "MVC proxy", via IModels. > > Maybe it's just my mistake, but maybe it is also a design issue in > wicket. Don't know yet. > > Nevertheless, I am trying out a new approach where model and wicket > are more strictly decoupled: wicket will only render what is managed > in a non-visual model that has a some sort of "facade" representation > which can be iterated and rendered. > > So it will be: > > Wicket (View) <-> Facade <-> (Model, Controller) > > Until now I have been wronlgy assuming that wicket can manage the > lifecycle of Model, View, Controller, but it truly becomes a mess with > serialization issues and complex logic. > > My 2cents ;) > > ** > 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
Re: A lesson learned about wicket
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
Re: A lesson learned about wicket
Hi Martin, trying to give you a qualified opinion on your post... Am 14.12.2011 um 09:12 schrieb Martin Makundi: > Hi! > > Today I have learned about a huge misconception I have had about wicket 1.4. > > I have actually been thinking that it is an MVC framework. > But it is practically not. Why? Wicket's request cycle and > serialization process makes effortless MVC design almost impossible. Struts is an 'MVC framework' but I can't remember that it made anything 'effortless'. Or asking differently: Is there _any_ MVC framework where things are effortless (™)? We would like to learn from that framework so we can improve :-) > It seems like wicket is just an "MVC proxy", via IModels. IModel just mediates between between M and VC. Basically you don't have to tweak your Model M so it fits into VC. Probably IModel should be renamed into IModelAdapterForPresentationLayer but that much typing would really not help anybody. > Maybe it's just my mistake, but maybe it is also a design issue in > wicket. Don't know yet. > > Nevertheless, I am trying out a new approach where model and wicket > are more strictly decoupled: wicket will only render what is managed > in a non-visual model that has a some sort of "facade" representation > which can be iterated and rendered. > > So it will be: > > Wicket (View) <-> Facade <-> (Model, Controller) Wicket (View) <-> Controller -> Facade (using interface IModel) + direct model access -> Model (Data) > Until now I have been wronlgy assuming that wicket can manage the > lifecycle of Model, View, Controller, but it truly becomes a mess with > serialization issues and complex logic. By putting your stuff into WebApplication, WebSession and Request you have the typical life cycles of an web application. Putting stuff into pages and transferring them to other pages by reference can even give you conversation-style scope. Also you can use stuff like 'Weld' where Igor wrote a nice article about integration into Wicket. So what exactly is the problem? If you don't like serialization you basically use something like LoadableDetachableModel. Serialization is needed to persist state across request over a stateless protocol like HTTP. It's not there to bully our users :-) If you can't serialize you need to restore state on your own using for example LoadableDetachableModel. > > 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
Re: A lesson learned about wicket
Hi! >>I have actually been thinking that [Wicket] is an MVC framework. > > Looking at all the other MVC web frameworks I'm glad it isn't. > > What issues are you trying to solve actually? That's a long story. We have complex business logic in complex multidimensional forms... yeah, don't try handling all that complexity dynamically in wicket, let wicket see just a facade. ** Martin > Sven > > Am 14.12.2011 09:12, schrieb Martin Makundi: >> >> Hi! >> >> Today I have learned about a huge misconception I have had about wicket >> 1.4. >> >> I have actually been thinking that it is an MVC framework. >> >> But it is practically not. Why? Wicket's request cycle and >> serialization process makes effortless MVC design almost impossible. >> It seems like wicket is just an "MVC proxy", via IModels. >> >> Maybe it's just my mistake, but maybe it is also a design issue in >> wicket. Don't know yet. >> >> Nevertheless, I am trying out a new approach where model and wicket >> are more strictly decoupled: wicket will only render what is managed >> in a non-visual model that has a some sort of "facade" representation >> which can be iterated and rendered. >> >> So it will be: >> >> Wicket (View)<-> Facade<-> (Model, Controller) >> >> Until now I have been wronlgy assuming that wicket can manage the >> lifecycle of Model, View, Controller, but it truly becomes a mess with >> serialization issues and complex logic. >> >> My 2cents ;) >> >> ** >> 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
Re: A lesson learned about wicket
Hi Martin, >I have actually been thinking that [Wicket] is an MVC framework. Looking at all the other MVC web frameworks I'm glad it isn't. What issues are you trying to solve actually? Sven Am 14.12.2011 09:12, schrieb Martin Makundi: Hi! Today I have learned about a huge misconception I have had about wicket 1.4. I have actually been thinking that it is an MVC framework. But it is practically not. Why? Wicket's request cycle and serialization process makes effortless MVC design almost impossible. It seems like wicket is just an "MVC proxy", via IModels. Maybe it's just my mistake, but maybe it is also a design issue in wicket. Don't know yet. Nevertheless, I am trying out a new approach where model and wicket are more strictly decoupled: wicket will only render what is managed in a non-visual model that has a some sort of "facade" representation which can be iterated and rendered. So it will be: Wicket (View)<-> Facade<-> (Model, Controller) Until now I have been wronlgy assuming that wicket can manage the lifecycle of Model, View, Controller, but it truly becomes a mess with serialization issues and complex logic. My 2cents ;) ** 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
A lesson learned about wicket
Hi! Today I have learned about a huge misconception I have had about wicket 1.4. I have actually been thinking that it is an MVC framework. But it is practically not. Why? Wicket's request cycle and serialization process makes effortless MVC design almost impossible. It seems like wicket is just an "MVC proxy", via IModels. Maybe it's just my mistake, but maybe it is also a design issue in wicket. Don't know yet. Nevertheless, I am trying out a new approach where model and wicket are more strictly decoupled: wicket will only render what is managed in a non-visual model that has a some sort of "facade" representation which can be iterated and rendered. So it will be: Wicket (View) <-> Facade <-> (Model, Controller) Until now I have been wronlgy assuming that wicket can manage the lifecycle of Model, View, Controller, but it truly becomes a mess with serialization issues and complex logic. My 2cents ;) ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
