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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to