> 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 > <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
