Re: Moving from Tapestry to Wicket?

[Eelco Hillenius <ee...@gmail.com>]

>> I have a complex table and many links on the page that are not
>> book-markable. Will that be a problem in terms of too much session
>> information?

The default session store in Wicket saves history in some temp files
and only holds the current page in memory (well, the current page of
any page map in case you use more). Say that's a very heavy page,
taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
You can support close to 10,000 concurrent sessions (close, because
obviously, you'll use memory for other things than just sessions).
Changes are that you run into bottlenecks with processors and database
utilization long before you run out of memory for one box.

The only kind of web sites I probably wouldn't recommend Wicket as
used by default for are sites like Google, Yahoo and CNN etc, where
you can have enormous spikes in traffic that are very short lived.
But... the good news with Wicket then again is that you can build your
app entirely using bookmarkable pages (even stateless if you want, so
that you can avoid *any* memory usage) so that clustering will be easy
and cheap. On top of that, you can plug in your own implementations of
things like session store so that you can decide when/ how/ where
state should be kept.

You have to weigh the benefits of the stateful programming model
against your technical requirements. But you can use Wicket for most
use cases if you give it a bit of thought.

>> Would it be conceptually easy for me to write Javascript/AJAX and hook them into Wicket in a simple way?

Yeah, that's fairly simple. You can either write snippets that are
used by components/ behaviors that integrate with our regular AJAX
engine, or you can even plugin your own engine if you'd prefer that.

>> Its all about cost.

The funny thing is that in most discussions out there people focus on
the cost of servers/ memory/ etc. While probably for most people -
basically for anything that doesn't have the size of Google -
development and maintenance cost is often the highest component. So a
good development model makes sense.

>> we have absolute faith that it will have a lot of users according to our business plan.

May I ask what you think is a lot (say hits per second and concurrent
sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
millions? If you're talking about really large numbers, you need to be
aware of the choices you make in your app, not only for Wicket
obviously, and test for scalability from the start. Though if you're
talking about thousands up to maybe a few thousands, Wicket should be
able to handle it fine without you having to worry about using
stateful components.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Moving from Tapestry to Wicket?

[Jeremy Thomerson <je...@wickettraining.com>]

I can vouch for the fact that Wicket's learning curve, compared to
Tapestry's, is MUCH, MUCH easier for an object-oriented Java programmer.  We
used Tapestry at my last place of employment, and I hated it.  When I left,
I chose Wicket, and for the past several years have been enjoying UI
development for the first time in my web app career.

You can get up and running in Wicket very quickly, and can really generate
some apps quickly.  The biggest thing is to make sure you have a solid
understanding of how to effectively use models before you begin a project -
or you'll kick yourself later.

I'm sure you'll enjoy your Wicket development experience - and the list is
very active and friendly - let us know if you need any help along the way.

-- 
Jeremy Thomerson
http://www.wickettraining.com

On Sun, Nov 2, 2008 at 10:23 AM, GK1971 <gr...@gmail.com> wrote:

>
> Hi Eelco,
>
> You are correct - right now my main worry is about development cost.
> Hardware cost is cheaper IMHO than having developers struggle with a hard
> framework and spending too much time trying to maintain and write code
> based
> around a hard framework.
>
> Honestly in our application (we have a roadmap for scalability) we are
> likely to get several hundred concurrent sessions per server with a few kb
> of state stored in the HTTPSession. Its not that much. What I was more
> concerned about was Page storage and storage that I can't control (for
> example, if I couldn't control IModel storage I would be concerned).
>
> We are unlikely to have spikes of traffic, but we are more likely to have
> dribs and drabs of users who potentially keep sessions open for perhaps
> minutes to hours.
>
> For our initial scaling the client will have an affinity to a specific
> server. We can control the number of users that we have on a server. We can
> then scale our servers horizontally if we hit a scaling issue on one of the
> servers. I'm starting not to worry about it too much.
>
> Honestly - I really face the same issues with Tapestry. What I don't face
> with Wicket is the development cost because it appears to be (I played with
> it yesterday) a very intelligent architecture. I was happy playing
> yesterday
> and even migrated our login page over very quickly. Of course I have to
> figure out how to handle my 'remember me' cookie and hit the database, but
> it all seems rather nice.
>
> Cheers, Graeme.
>
>
> Eelco Hillenius wrote:
> >
> >>> I have a complex table and many links on the page that are not
> >>> book-markable. Will that be a problem in terms of too much session
> >>> information?
> >
> > The default session store in Wicket saves history in some temp files
> > and only holds the current page in memory (well, the current page of
> > any page map in case you use more). Say that's a very heavy page,
> > taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
> > You can support close to 10,000 concurrent sessions (close, because
> > obviously, you'll use memory for other things than just sessions).
> > Changes are that you run into bottlenecks with processors and database
> > utilization long before you run out of memory for one box.
> >
> > The only kind of web sites I probably wouldn't recommend Wicket as
> > used by default for are sites like Google, Yahoo and CNN etc, where
> > you can have enormous spikes in traffic that are very short lived.
> > But... the good news with Wicket then again is that you can build your
> > app entirely using bookmarkable pages (even stateless if you want, so
> > that you can avoid *any* memory usage) so that clustering will be easy
> > and cheap. On top of that, you can plug in your own implementations of
> > things like session store so that you can decide when/ how/ where
> > state should be kept.
> >
> > You have to weigh the benefits of the stateful programming model
> > against your technical requirements. But you can use Wicket for most
> > use cases if you give it a bit of thought.
> >
> >>> Would it be conceptually easy for me to write Javascript/AJAX and hook
> >>> them into Wicket in a simple way?
> >
> > Yeah, that's fairly simple. You can either write snippets that are
> > used by components/ behaviors that integrate with our regular AJAX
> > engine, or you can even plugin your own engine if you'd prefer that.
> >
> >>> Its all about cost.
> >
> > The funny thing is that in most discussions out there people focus on
> > the cost of servers/ memory/ etc. While probably for most people -
> > basically for anything that doesn't have the size of Google -
> > development and maintenance cost is often the highest component. So a
> > good development model makes sense.
> >
> >>> we have absolute faith that it will have a lot of users according to
> our
> >>> business plan.
> >
> > May I ask what you think is a lot (say hits per second and concurrent
> > sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
> > millions? If you're talking about really large numbers, you need to be
> > aware of the choices you make in your app, not only for Wicket
> > obviously, and test for scalability from the start. Though if you're
> > talking about thousands up to maybe a few thousands, Wicket should be
> > able to handle it fine without you having to worry about using
> > stateful components.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20291214.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Moving from Tapestry to Wicket?

[Graeme Knight <gr...@gmail.com>]

Hey Eelco!

Awesome! Thanks for your answers - they really helped. I appreciate the
time. BTW, Wicket in Action is a really well written book compared to others
in the genre. Thanks to you and Martijn for the hard work! It came at the
right time for me and we have decided to make the move from Tapestry.

Let you know how it goes, and I'll be on the forums plenty I am sure!

Cheers, Graeme.


Eelco Hillenius wrote:
> 
>> Honestly in our application (we have a roadmap for scalability) we are
>> likely to get several hundred concurrent sessions per server with a few
>> kb
>> of state stored in the HTTPSession. Its not that much.
> 
> That's definitively no problem for even a very modest setup.
> 
>> What I was more
>> concerned about was Page storage and storage that I can't control (for
>> example, if I couldn't control IModel storage I would be concerned).
> 
> Well, when using any framework that abstracts stuff for you, you'll
> trade convenience for transparency. I believe Wicket's architecture is
> very open and it is easy enough to customize how it works for what you
> want, but the more you want to deviate from the default, the more work
> it'll be. I think you should just build the darn thing and optimize
> when you have proof (through load testing for instance) that you are
> hitting a bottle neck. :-)
> 
> Do try to work with detachable models (LoadableDetachableModel is my
> favorite) where you can, because that will save considerably
> especially with complex domain models and avoid lazy loading problems
> with frameworks like Hibernate.
> 
>> We are unlikely to have spikes of traffic, but we are more likely to have
>> dribs and drabs of users who potentially keep sessions open for perhaps
>> minutes to hours.
> 
> Not a problem at all.
> 
>> For our initial scaling the client will have an affinity to a specific
>> server. We can control the number of users that we have on a server. We
>> can
>> then scale our servers horizontally if we hit a scaling issue on one of
>> the
>> servers. I'm starting not to worry about it too much.
> 
> Yeah, with just a few hundred users clustering won't be much of a
> problem either. Once you start to hit tens of thousands of concurrent
> sessions you have to take this stuff more seriously, but until then in
> my experience you'll be tweaking your database and business logic etc
> way before Wicket gets to be in the way :-)
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20328386.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Moving from Tapestry to Wicket?

[Eelco Hillenius <ee...@gmail.com>]

> Honestly in our application (we have a roadmap for scalability) we are
> likely to get several hundred concurrent sessions per server with a few kb
> of state stored in the HTTPSession. Its not that much.

That's definitively no problem for even a very modest setup.

> What I was more
> concerned about was Page storage and storage that I can't control (for
> example, if I couldn't control IModel storage I would be concerned).

Well, when using any framework that abstracts stuff for you, you'll
trade convenience for transparency. I believe Wicket's architecture is
very open and it is easy enough to customize how it works for what you
want, but the more you want to deviate from the default, the more work
it'll be. I think you should just build the darn thing and optimize
when you have proof (through load testing for instance) that you are
hitting a bottle neck. :-)

Do try to work with detachable models (LoadableDetachableModel is my
favorite) where you can, because that will save considerably
especially with complex domain models and avoid lazy loading problems
with frameworks like Hibernate.

> We are unlikely to have spikes of traffic, but we are more likely to have
> dribs and drabs of users who potentially keep sessions open for perhaps
> minutes to hours.

Not a problem at all.

> For our initial scaling the client will have an affinity to a specific
> server. We can control the number of users that we have on a server. We can
> then scale our servers horizontally if we hit a scaling issue on one of the
> servers. I'm starting not to worry about it too much.

Yeah, with just a few hundred users clustering won't be much of a
problem either. Once you start to hit tens of thousands of concurrent
sessions you have to take this stuff more seriously, but until then in
my experience you'll be tweaking your database and business logic etc
way before Wicket gets to be in the way :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Moving from Tapestry to Wicket?

[GK1971 <gr...@gmail.com>]

Hi Eelco,

You are correct - right now my main worry is about development cost.
Hardware cost is cheaper IMHO than having developers struggle with a hard
framework and spending too much time trying to maintain and write code based
around a hard framework. 

Honestly in our application (we have a roadmap for scalability) we are
likely to get several hundred concurrent sessions per server with a few kb
of state stored in the HTTPSession. Its not that much. What I was more
concerned about was Page storage and storage that I can't control (for
example, if I couldn't control IModel storage I would be concerned). 

We are unlikely to have spikes of traffic, but we are more likely to have
dribs and drabs of users who potentially keep sessions open for perhaps
minutes to hours.

For our initial scaling the client will have an affinity to a specific
server. We can control the number of users that we have on a server. We can
then scale our servers horizontally if we hit a scaling issue on one of the
servers. I'm starting not to worry about it too much.

Honestly - I really face the same issues with Tapestry. What I don't face
with Wicket is the development cost because it appears to be (I played with
it yesterday) a very intelligent architecture. I was happy playing yesterday
and even migrated our login page over very quickly. Of course I have to
figure out how to handle my 'remember me' cookie and hit the database, but
it all seems rather nice.

Cheers, Graeme.


Eelco Hillenius wrote:
> 
>>> I have a complex table and many links on the page that are not
>>> book-markable. Will that be a problem in terms of too much session
>>> information?
> 
> The default session store in Wicket saves history in some temp files
> and only holds the current page in memory (well, the current page of
> any page map in case you use more). Say that's a very heavy page,
> taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
> You can support close to 10,000 concurrent sessions (close, because
> obviously, you'll use memory for other things than just sessions).
> Changes are that you run into bottlenecks with processors and database
> utilization long before you run out of memory for one box.
> 
> The only kind of web sites I probably wouldn't recommend Wicket as
> used by default for are sites like Google, Yahoo and CNN etc, where
> you can have enormous spikes in traffic that are very short lived.
> But... the good news with Wicket then again is that you can build your
> app entirely using bookmarkable pages (even stateless if you want, so
> that you can avoid *any* memory usage) so that clustering will be easy
> and cheap. On top of that, you can plug in your own implementations of
> things like session store so that you can decide when/ how/ where
> state should be kept.
> 
> You have to weigh the benefits of the stateful programming model
> against your technical requirements. But you can use Wicket for most
> use cases if you give it a bit of thought.
> 
>>> Would it be conceptually easy for me to write Javascript/AJAX and hook
>>> them into Wicket in a simple way?
> 
> Yeah, that's fairly simple. You can either write snippets that are
> used by components/ behaviors that integrate with our regular AJAX
> engine, or you can even plugin your own engine if you'd prefer that.
> 
>>> Its all about cost.
> 
> The funny thing is that in most discussions out there people focus on
> the cost of servers/ memory/ etc. While probably for most people -
> basically for anything that doesn't have the size of Google -
> development and maintenance cost is often the highest component. So a
> good development model makes sense.
> 
>>> we have absolute faith that it will have a lot of users according to our
>>> business plan.
> 
> May I ask what you think is a lot (say hits per second and concurrent
> sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
> millions? If you're talking about really large numbers, you need to be
> aware of the choices you make in your app, not only for Wicket
> obviously, and test for scalability from the start. Though if you're
> talking about thousands up to maybe a few thousands, Wicket should be
> able to handle it fine without you having to worry about using
> stateful components.
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20291214.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org