You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Makundi <ma...@koodaripalvelut.com> on 2011/12/14 09:12:21 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Peter Ertl <pe...@gmx.org>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> 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
> <ma...@koodaripalvelut.com> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: A lesson learned about wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ma...@koodaripalvelut.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org