You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Eyal Golan <eg...@gmail.com> on 2008/06/01 22:53:03 UTC
What is Wicket? from WIA
Hi,
I read chapter 1 in Wicket in Action and I have a question.
in section 1.2.1 it says:
"You can get rid of all of these problems by using Wicket. It is a
stateful framework, so you
don't have to follow the REST (though you can, but we will talk about
that later in this book)
approach. The main idea behind REST is scalability. Fine. But let me make a
bold statement here:
Very often, REST is premature optimization."
Wicket is my first Web Framework and I was wondering if someone can explain
why Wicket solves the REST problem (which I understood the problem itself).
Is it because in Wicket we don;t need to pass parameters in the request? And
instead we create pages with the necessary information? (or something like
that)
Thank
--
Eyal Golan
egolan74@gmail.com
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
Re: What is Wicket? from WIA
Posted by Eyal Golan <eg...@gmail.com>.
wow.
thanks.
That was very helpful :)
Eyal
On Mon, Jun 2, 2008 at 12:08 AM, Eelco Hillenius <ee...@gmail.com>
wrote:
> Wicket supports private state for individual components, whereas the
> traditional (REST) pattern assumes to take the state out (to string
> based request parameters) and up to the request level. The big
> difference is that without using a framework like Wicket, you can't
> really create self contained components. You have to ensure that state
> gets passed in any URL that is generated on a page, ensure the
> parameters are properly scoped, have to worry about how to serialize
> and de-serialize (from regular objects to strings and vice versa),
> etc.
>
> You can test this by creating a Struts app where you create a pageable
> list. You'd append parameters for e.g. the page number and query to
> every URL that passes back to the page, even if the link you are
> constructing has nothing to do with the pageable list. Just the fact
> that it is on the page means you have to pass the parameter. That by
> itself is doable - though destroys encapsulation -; the problems
> really start when you decide to move/ reuse the 'component' to/ in
> another page, and when e.g. you add more things to the pass that need
> to pass state like for instance tabs.
>
> Eelco
>
> On Sun, Jun 1, 2008 at 1:53 PM, Eyal Golan <eg...@gmail.com> wrote:
> > Hi,
> > I read chapter 1 in Wicket in Action and I have a question.
> > in section 1.2.1 it says:
> > "You can get rid of all of these problems by using Wicket. It is a
> > stateful framework, so you
> > don't have to follow the REST (though you can, but we will talk
> about
> > that later in this book)
> > approach. The main idea behind REST is scalability. Fine. But let me make
> a
> > bold statement here:
> > Very often, REST is premature optimization."
> >
> > Wicket is my first Web Framework and I was wondering if someone can
> explain
> > why Wicket solves the REST problem (which I understood the problem
> itself).
> > Is it because in Wicket we don;t need to pass parameters in the request?
> And
> > instead we create pages with the necessary information? (or something
> like
> > that)
> >
> > Thank
> >
> > --
> > Eyal Golan
> > egolan74@gmail.com
> >
> > Visit: http://jvdrums.sourceforge.net/
> > LinkedIn: http://www.linkedin.com/in/egolan74
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Eyal Golan
egolan74@gmail.com
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
Re: What is Wicket? from WIA
Posted by Eelco Hillenius <ee...@gmail.com>.
Wicket supports private state for individual components, whereas the
traditional (REST) pattern assumes to take the state out (to string
based request parameters) and up to the request level. The big
difference is that without using a framework like Wicket, you can't
really create self contained components. You have to ensure that state
gets passed in any URL that is generated on a page, ensure the
parameters are properly scoped, have to worry about how to serialize
and de-serialize (from regular objects to strings and vice versa),
etc.
You can test this by creating a Struts app where you create a pageable
list. You'd append parameters for e.g. the page number and query to
every URL that passes back to the page, even if the link you are
constructing has nothing to do with the pageable list. Just the fact
that it is on the page means you have to pass the parameter. That by
itself is doable - though destroys encapsulation -; the problems
really start when you decide to move/ reuse the 'component' to/ in
another page, and when e.g. you add more things to the pass that need
to pass state like for instance tabs.
Eelco
On Sun, Jun 1, 2008 at 1:53 PM, Eyal Golan <eg...@gmail.com> wrote:
> Hi,
> I read chapter 1 in Wicket in Action and I have a question.
> in section 1.2.1 it says:
> "You can get rid of all of these problems by using Wicket. It is a
> stateful framework, so you
> don't have to follow the REST (though you can, but we will talk about
> that later in this book)
> approach. The main idea behind REST is scalability. Fine. But let me make a
> bold statement here:
> Very often, REST is premature optimization."
>
> Wicket is my first Web Framework and I was wondering if someone can explain
> why Wicket solves the REST problem (which I understood the problem itself).
> Is it because in Wicket we don;t need to pass parameters in the request? And
> instead we create pages with the necessary information? (or something like
> that)
>
> Thank
>
> --
> Eyal Golan
> egolan74@gmail.com
>
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org