Moving from Tapestry to Wicket?

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

Hi. I hope this email is appropriate for the forum - its my first time
posting.

My partner and I are in the process of working on a site that currently uses
Tapestry 4 and must be reasonably scalable vertically (we have horizontally
covered in a road map). I am looking around at technologies that we can
pursue in the future that will provide us with a way of creating a wonderful
experience for a user based on dynamic content with Java as a base language.

I have used Tapestry 3 and 4 in prior lives in prior companies and as
Tapestry 5 was still early a year ago when we started the project I decided
to work with Tapestry 4 an understand that once the site was up and running
we may look at rewriting the web layer in an updated framework, using the
lessons we had learned along the way about our specific application.

I have grown unhappy with Tapestry generally - for example, its clumsy
handling of AJAX. Even a seasoned developer can write a Tapestry application
which is incredibly complex and inefficient, also. I'm not certain its
declarative approach in Tapestry 5 is a wise thing from a productivity point
of view (maintenance). Debugging a Tapestry application can be difficult.

I found myself looking at JSF, but we'd like to actually deliver a
functioning site quickly and not have our hands tied by bureaucracy. I also
looked into other frameworks, and short of writing something myself I have
found the best for our needs to be Tapestry 5 (scares me - what will
Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.

I'm liking the look of Wicket but I wondered if it would fill a few ideas I
have.

I have had significant issues with DOJO/Tapestry bugs that I cannot fix
myself and that has limited productivity. I would like to write an AJAX
library for myself and hook it into Wicket somehow. Would this be possible.
I feel it may be a pain in Tapestry because there 'appears' to be such a
high coupling with DOJO now. Would it be conceptually easy for me to write
Javascript/AJAX and hook them into Wicket in a simple way? I understand
Wicket has a good framework for AJAX but if I require to implement code of
my own, is it easy to slip under the hood (with Tapestry this is very hard).

Many forums have mentioned scalability is an issue, but I believe that this
is down to an applications individual handling of state rather than the
framework. Am I correct? I am not so worried about this vertical scaling as
long as I can horizontally scale my application on many servers (which I can
if I control state).

What's the road map for Wicket? I understand it is now one of the main
Apache projects (which is one reason I am looking at it), so I assume it
won't disappear sometime next year after I have invested time and effort
into developing with it.

Please tell me you are not going to pull a 'Tapestry' on me and other users
by making future versions so ridiculously incompatible I have to rewrite my
project again?

Honestly, I'm looking for a framework that will allow me to:

1) Utilize HTML templates (which you do, I understand).
2) Utilize CSS (which you do) files externally for my artist.
3) Utilize Javascript (which I assume you do).
4) Utilize a Java, component based web framework for creating a fast
lightweight but rich user experience for my users (which I guess you do).

I have just purchased Wicket in Action so as I can do some research, but I
do appreciate your time if possible.

Many thanks for your help, and your help.

Regards, Graeme.
-- 
View this message in context: http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20254394.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?

[Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>]

1) Utilize HTML templates (which you do, I understand).
All good
2) Utilize CSS (which you do) files externally for my artist.
All good
3) Utilize Javascript (which I assume you do).
All good, and excellent support for integration creating your own ajax 
components.
> 4) Utilize a Java, component based web framework for creating a fast
> lightweight but rich user experience for my users (which I guess you do).
>   
All good:)
> I have just purchased Wicket in Action so as I can do some research, but I
> do appreciate your time if possible.
>
> Many thanks for your help, and your help.
>
> Regards, Graeme.
>   
And I do not believe the core guys would break mutilate the API in a 
high degree, when I converted a project from 1.2 to 1.3 it took around 2 
days. Going from 1.3 to 1.4 should take around the same.. This I belive 
of course depends on your project sizes, and how DRY you are:) I think 
there may be minor breaks once in a while but the biggest where from 1.3 
to 1.4. Introducing generics.

-- 
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


---------------------------------------------------------------------
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?

[James Carman <ja...@carmanconsulting.com>]

On Thu, Oct 30, 2008 at 4:24 PM, GK1971 <gr...@gmail.com> wrote:
>
> Hi.
>
> You are possibly correct. My main concern is that I have to upgrade from
> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in the
> least I have allowed myself to look at the options.

Well, the backward compatibility thing was the reason I switched.
That was enough for me.  I used Tapestry 4 and wrote a lot of
framework code for it (Tapernate, Acegi Integration, etc.) and even
contributed to Tapestry itself (how do you like autowiring support?).
When I found out that I would have to re-write everything for Tapestry
5, I decided that my time would best be spent elsewhere.  Howard told
me face-to-face at NFJS Cincinnati that it would be virtually
impossible to provide an easy migration path to upgrade from 4 to 5.
I voiced my concerns about backward compatibility to the Tapestry
community:

http://markmail.org/message/mrspncgyidolysyn#query:james%20carman%20tapestry%20compatibility+page:1+mid:ompdzicnbeyfwygk+state:results

http://www.mail-archive.com/users@tapestry.apache.org/msg03279.html

As you can see, it fell on deaf (and sometimes condescending) ears.

---------------------------------------------------------------------
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?

[Ernesto Reinaldo Barreiro <re...@gmail.com>]

Hi,

In my experience, almost two years using it, Wicket has a rather
stable-backwarks-compatible API. Maybe  the biggest API break I have
experienced was when branch 2.0 was declared a dead end and early 2.0
adopters had to re-adapt their code back to 1.3.x... Even migrating to
1.4 generics was not so painful...

Most of the time I just use the SVN trunk  for development because it is
rather stable (I have know of projects going into production using just
an snapshot of the trunk)  and you continually  get new fixes (and can
early adapt to new features).  I find the API is very configurable and
almost at all places you find  hooks  you can use to tweak Wicket  to
work as you want.  Besides that  the developers community is very active
and responsive to users demands (if they are good for Wicket, of course).

Best,

Ernesto

GK1971 wrote:
> Hi.
>
> You are possibly correct. My main concern is that I have to upgrade from
> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in the
> least I have allowed myself to look at the options.
>
> I guess I am really asking for reasons to move from Tapestry to Wicket -
> particularlu if anyone has any experience of doing this which they could
> share. What were those reasons, and pros/cons after sampling both solutions.
>
> Thanks for pointing out that I was not clear.
>
>
> Daniel Frisk wrote:
>   
>> I actually read your mail but I didn't quite get it, what is your main  
>> concern?
>> It seems to me like Wicket would be a perfect fit to your four criteria.
>>
>> // Daniel
>> jalbum.net
>>
>>
>> On 2008-10-30, at 21:05, GK1971 wrote:
>>
>>     
>>> Hi. I hope this email is appropriate for the forum - its my first time
>>> posting.
>>>
>>> My partner and I are in the process of working on a site that  
>>> currently uses
>>> Tapestry 4 and must be reasonably scalable vertically (we have  
>>> horizontally
>>> covered in a road map). I am looking around at technologies that we  
>>> can
>>> pursue in the future that will provide us with a way of creating a  
>>> wonderful
>>> experience for a user based on dynamic content with Java as a base  
>>> language.
>>>
>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>> Tapestry 5 was still early a year ago when we started the project I  
>>> decided
>>> to work with Tapestry 4 an understand that once the site was up and  
>>> running
>>> we may look at rewriting the web layer in an updated framework,  
>>> using the
>>> lessons we had learned along the way about our specific application.
>>>
>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>> handling of AJAX. Even a seasoned developer can write a Tapestry  
>>> application
>>> which is incredibly complex and inefficient, also. I'm not certain its
>>> declarative approach in Tapestry 5 is a wise thing from a  
>>> productivity point
>>> of view (maintenance). Debugging a Tapestry application can be  
>>> difficult.
>>>
>>> I found myself looking at JSF, but we'd like to actually deliver a
>>> functioning site quickly and not have our hands tied by bureaucracy.  
>>> I also
>>> looked into other frameworks, and short of writing something myself  
>>> I have
>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>
>>> I'm liking the look of Wicket but I wondered if it would fill a few  
>>> ideas I
>>> have.
>>>
>>> I have had significant issues with DOJO/Tapestry bugs that I cannot  
>>> fix
>>> myself and that has limited productivity. I would like to write an  
>>> AJAX
>>> library for myself and hook it into Wicket somehow. Would this be  
>>> possible.
>>> I feel it may be a pain in Tapestry because there 'appears' to be  
>>> such a
>>> high coupling with DOJO now. Would it be conceptually easy for me to  
>>> write
>>> Javascript/AJAX and hook them into Wicket in a simple way? I  
>>> understand
>>> Wicket has a good framework for AJAX but if I require to implement  
>>> code of
>>> my own, is it easy to slip under the hood (with Tapestry this is  
>>> very hard).
>>>
>>> Many forums have mentioned scalability is an issue, but I believe  
>>> that this
>>> is down to an applications individual handling of state rather than  
>>> the
>>> framework. Am I correct? I am not so worried about this vertical  
>>> scaling as
>>> long as I can horizontally scale my application on many servers  
>>> (which I can
>>> if I control state).
>>>
>>> What's the road map for Wicket? I understand it is now one of the main
>>> Apache projects (which is one reason I am looking at it), so I  
>>> assume it
>>> won't disappear sometime next year after I have invested time and  
>>> effort
>>> into developing with it.
>>>
>>> Please tell me you are not going to pull a 'Tapestry' on me and  
>>> other users
>>> by making future versions so ridiculously incompatible I have to  
>>> rewrite my
>>> project again?
>>>
>>> Honestly, I'm looking for a framework that will allow me to:
>>>
>>> 1) Utilize HTML templates (which you do, I understand).
>>> 2) Utilize CSS (which you do) files externally for my artist.
>>> 3) Utilize Javascript (which I assume you do).
>>> 4) Utilize a Java, component based web framework for creating a fast
>>> lightweight but rich user experience for my users (which I guess you  
>>> do).
>>>
>>> I have just purchased Wicket in Action so as I can do some research,  
>>> but I
>>> do appreciate your time if possible.
>>>
>>> Many thanks for your help, and your help.
>>>
>>> Regards, Graeme.
>>>       
>> ---------------------------------------------------------------------
>> 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

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?

[Adib Saikali <ad...@programmingmastery.com>]

On Fri, Oct 31, 2008 at 11:17 AM, GK1971 <gr...@gmail.com> wrote:

>
> Hi guys,
>
> I think the responses alone are almost swaying me toward Wicket - I sense a
> strong community. That has been a problem for my in other frameworks where
> there is no sense of community and input is not welcome.
>
> Concerning state: My web application really is an application, rather than
> a
> simple stateless site. Developing it using a restful model will mean (I
> assume) exposing information about the internals to the client. I don't
> want
> to do this if I can help it - we are so secure that we run using a SSL
> cert.
> I store quite a bit of state in the HTTP session in my Tapestry
> implementation now. I am not happy with the information in the URLs,
> personally. Would Wicket help me out here?
>
> 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?


I am wicket user  I have spent some time reading the wicket source code and
wicket has an interface called ISessionStore which it uses to  store your
state in. There is an HTTP session implementation of ISessionStore but if
you end up with a crazy amount of state you can in theroy implement your own
version of this session store which used some sort of hyprid strategy where
some of the session store can be put into a db and the rest in http session,
or maybe you can have the your implementation of session store sit on top of
a distributed cache and you end up putting nothing in the http session, your
distributed cache can take care of replicating the state accross servers. I
don't think you will have to go to such an extent.

The app I am working on has a lot of state and hopefully a lot of users when
it running it is not trivial and my investigation of the wicket source code
gave me confidence that I can get wicket to do what I want it to. Also
tracing through wicket in the debugger was not hard at all except for a
small section which used a state machine that I hope can be refactored by
the wicket developers some day in something that is more easily
understanable its too twisted in the 1.3 code base.





>
> Honesty - I believe computers/memory/storage is becoming cheaper and that
> ramping up servers which allow less users to run because an application is
> not stateful is an investment I am willing to make - IF it means a cut in
> cost of development, and stability of the application is better, including
> testing, etc. With the money I save in development I can buy more servers.
>
> Myself and my partner are almost certain to switch to Wicket and away from
> Tapestry. Its all about cost. And we are building a web application with
> only our own money, no investment, and we have absolute faith that it will
> have a lot of users according to our business plan. This decision is an
> important one for us. Obviously having no investment means I can switch to
> a
> framework and do a rewrite if I want to (now), but obviously long term I
> want to stay with my choice.
>
> Please - any further comments would be welcome.
>
> Appreciate your time, Graeme.
>
>
> igor.vaynberg wrote:
> >
> > state is always a "scarry" thing for users coming from a stateless
> > framework, but really its a myth. you can find plenty of threads in
> > the archives of this list on this topic. thoof.com used wicket and it
> > received as much traffic as digg at some ponts. too bad they ran out
> > of money because it was a great example of a public wicket app that
> > was under a huge load.
> >
> > the only way for you to measure this is to create a prototype that has
> > a couple of fairly complex pages representative of your application,
> > deploy it into a clustered environment, hammer it, and gather some
> > stats.
> >
> > wicket also has a few extension points which allow you to manually
> > optimize state per page or per component, but those are only used in
> > extreme circumstances.
> >
> > what state does get you is a much better programming model so you can
> > develop your project much faster then in restful frameworks. wicket
> > projects also scale very well across large dev teams.
> >
> > as far as backwards compatibility across releases, we believe in
> > evolutionary approach rather then revolutionary. we do break the api
> > across major releases, but because the core concepts of wicket are
> > very stable the api breaks tend to be fairly easy to fix.
> >
> > i used to develop in t3 and t4 before wicket. what made me switch,
> > among the good old api breaks, was:
> >
> > wicket offers true encapsulation in components
> >
> > form processing is much better then rewinding crap in tapestry which
> > makes it very difficult to do anything outside the box for complex
> > forms
> >
> > and most importantly, wicket's component hierarchy is completely
> > dynamic. you can insert, remove, replace components at any point.
> > tapestry's component hierarchy is static, once the page is built its
> > hard to change its representation. blocks do make some changes
> > possible, but very limiting. consider this: in wicket you can build
> > your entire application as a single page simply swapping parts for
> > navigation.
> >
> > i quit using tapestry before it had ajax support so i cant really
> > comment on it. what i can comment out is that wicket's ajax support is
> > fairly transparent, you can do most things without writing javascript,
> > and because ajax responses are rendered on server you dont need to
> > implement logic on the client in js.
> >
> > -igor
> >
> > On Fri, Oct 31, 2008 at 4:55 AM, GK1971 <gr...@gmail.com> wrote:
> >>
> >> Hi.
> >>
> >> Thank you all for your input. Very valuable. I started reading Wicket In
> >> Action last night and I like how the book is written - very much. It has
> >> the
> >> right explanations in the right places. So, I'm becoming convinced to
> try
> >> it. But I have concerns around the handling of state. I understand this
> >> is
> >> probably where people do have concerns and I know I am not the first to
> >> ask.
> >>
> >> I want to imagine myself in a position where I have a fairly rich web
> >> application that is publically available on the web, where people can
> >> join
> >> by invitation and have a great user experience. All this may take some
> >> state. Everyone talks about the RESTful model these days but I'm not
> >> convinced thats either new or wise all of the time. What it does allow
> >> you
> >> is easy scalability.
> >>
> >> What are the best ways to scale a Wicket built application across
> >> multiple
> >> servers? I'm assuming Layer 7 load balancers. With bigger state stored
> >> (is
> >> that true?) than an average web app that may mean less users
> concurrently
> >> per server, but of course you can add more servers.
> >>
> >> Does anyone have any experience with this? Has this automatic handling
> of
> >> state ever been an issue for anyone?
> >>
> >> Thanks, Graeme.
> >>
> >>
> >> Martin Voigt wrote:
> >>>
> >>> while I haven't migrated any big app from tapestry to wicket (but i
> >>> know tapestry nonetheless), the number one reason to do so would be
> >>> (at least for me) this: wicket is driven by usability (from the
> >>> developers pov) and tapestry is driven by technology. while one does
> >>> not exclude the other, wicket's approach is the better one. i've seen
> >>> java web frameworks come and go, and i watched wicket's progress for
> >>> ages now, and wicket still get's easier to use with each version while
> >>> advancing in terms of technology where it makes sense.
> >>>
> >>> and for the concern about scalability, wicket goes the easy road: more
> >>> load? add some servers and go with the standard apache plus mod-jk
> >>> session sticky thingy or whatever is you load balancer of choice.
> >>>
> >>> but the main reason still would be the developer-friendliness of
> >>> wicket, cos most things are too easy to believe, i18n for example, or
> >>> the serving of error pages. I'm not writing this because I get
> >>> something from promoting wicket, but I did several projects migrating
> >>> to wicket or using it from scratch, and it really delivers what it
> >>> promises.  it made me like java again ;)
> >>>
> >>> Regardsm
> >>> Martin
> >>>
> >>>
> >>> 2008/10/30 GK1971 <gr...@gmail.com>:
> >>>>
> >>>> Hi.
> >>>>
> >>>> You are possibly correct. My main concern is that I have to upgrade
> >>>> from
> >>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
> >>>> the
> >>>> least I have allowed myself to look at the options.
> >>>>
> >>>> I guess I am really asking for reasons to move from Tapestry to Wicket
> >>>> -
> >>>> particularlu if anyone has any experience of doing this which they
> >>>> could
> >>>> share. What were those reasons, and pros/cons after sampling both
> >>>> solutions.
> >>>>
> >>>> Thanks for pointing out that I was not clear.
> >>>>
> >>>>
> >>>> Daniel Frisk wrote:
> >>>>>
> >>>>> I actually read your mail but I didn't quite get it, what is your
> main
> >>>>> concern?
> >>>>> It seems to me like Wicket would be a perfect fit to your four
> >>>>> criteria.
> >>>>>
> >>>>> // Daniel
> >>>>> jalbum.net
> >>>>>
> >>>>>
> >>>>> On 2008-10-30, at 21:05, GK1971 wrote:
> >>>>>
> >>>>>>
> >>>>>> Hi. I hope this email is appropriate for the forum - its my first
> >>>>>> time
> >>>>>> posting.
> >>>>>>
> >>>>>> My partner and I are in the process of working on a site that
> >>>>>> currently uses
> >>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
> >>>>>> horizontally
> >>>>>> covered in a road map). I am looking around at technologies that we
> >>>>>> can
> >>>>>> pursue in the future that will provide us with a way of creating a
> >>>>>> wonderful
> >>>>>> experience for a user based on dynamic content with Java as a base
> >>>>>> language.
> >>>>>>
> >>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and
> as
> >>>>>> Tapestry 5 was still early a year ago when we started the project I
> >>>>>> decided
> >>>>>> to work with Tapestry 4 an understand that once the site was up and
> >>>>>> running
> >>>>>> we may look at rewriting the web layer in an updated framework,
> >>>>>> using the
> >>>>>> lessons we had learned along the way about our specific application.
> >>>>>>
> >>>>>> I have grown unhappy with Tapestry generally - for example, its
> >>>>>> clumsy
> >>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
> >>>>>> application
> >>>>>> which is incredibly complex and inefficient, also. I'm not certain
> >>>>>> its
> >>>>>> declarative approach in Tapestry 5 is a wise thing from a
> >>>>>> productivity point
> >>>>>> of view (maintenance). Debugging a Tapestry application can be
> >>>>>> difficult.
> >>>>>>
> >>>>>> I found myself looking at JSF, but we'd like to actually deliver a
> >>>>>> functioning site quickly and not have our hands tied by bureaucracy.
> >>>>>> I also
> >>>>>> looked into other frameworks, and short of writing something myself
> >>>>>> I have
> >>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
> >>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and
> Wicket.
> >>>>>>
> >>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
> >>>>>> ideas I
> >>>>>> have.
> >>>>>>
> >>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
> >>>>>> fix
> >>>>>> myself and that has limited productivity. I would like to write an
> >>>>>> AJAX
> >>>>>> library for myself and hook it into Wicket somehow. Would this be
> >>>>>> possible.
> >>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
> >>>>>> such a
> >>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
> >>>>>> write
> >>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
> >>>>>> understand
> >>>>>> Wicket has a good framework for AJAX but if I require to implement
> >>>>>> code of
> >>>>>> my own, is it easy to slip under the hood (with Tapestry this is
> >>>>>> very hard).
> >>>>>>
> >>>>>> Many forums have mentioned scalability is an issue, but I believe
> >>>>>> that this
> >>>>>> is down to an applications individual handling of state rather than
> >>>>>> the
> >>>>>> framework. Am I correct? I am not so worried about this vertical
> >>>>>> scaling as
> >>>>>> long as I can horizontally scale my application on many servers
> >>>>>> (which I can
> >>>>>> if I control state).
> >>>>>>
> >>>>>> What's the road map for Wicket? I understand it is now one of the
> >>>>>> main
> >>>>>> Apache projects (which is one reason I am looking at it), so I
> >>>>>> assume it
> >>>>>> won't disappear sometime next year after I have invested time and
> >>>>>> effort
> >>>>>> into developing with it.
> >>>>>>
> >>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
> >>>>>> other users
> >>>>>> by making future versions so ridiculously incompatible I have to
> >>>>>> rewrite my
> >>>>>> project again?
> >>>>>>
> >>>>>> Honestly, I'm looking for a framework that will allow me to:
> >>>>>>
> >>>>>> 1) Utilize HTML templates (which you do, I understand).
> >>>>>> 2) Utilize CSS (which you do) files externally for my artist.
> >>>>>> 3) Utilize Javascript (which I assume you do).
> >>>>>> 4) Utilize a Java, component based web framework for creating a fast
> >>>>>> lightweight but rich user experience for my users (which I guess you
> >>>>>> do).
> >>>>>>
> >>>>>> I have just purchased Wicket in Action so as I can do some research,
> >>>>>> but I
> >>>>>> do appreciate your time if possible.
> >>>>>>
> >>>>>> Many thanks for your help, and your help.
> >>>>>>
> >>>>>> Regards, Graeme.
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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--tp20254394p20254748.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
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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--tp20254394p20264444.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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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--tp20254394p20271517.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?

[Igor Vaynberg <ig...@gmail.com>]

On Fri, Oct 31, 2008 at 11:17 AM, GK1971 <gr...@gmail.com> wrote:
> Concerning state: My web application really is an application, rather than a
> simple stateless site. Developing it using a restful model will mean (I
> assume) exposing information about the internals to the client. I don't want
> to do this if I can help it - we are so secure that we run using a SSL cert.

with wicket you do not have any information in the url. for example a
url to delete a user with id 1005 might look something like this
server.com/context/?wicket:interface=:4:table.4.delete:ILinkListener

where table.4 is the component path to the link which internally
points to user 1005

the only place where you may potentially expose primary keys is when
you are rendering choice components: eg select boxes, etc, but even
there we give you an index variable to use alternatively. see
IChoiceRenderer.

if security is a concern wicket is probably the best framework out
there. even the urls themselves are session relative. and if you want
you can easily encrypt them completely so they can look like
?x=jj23h4j2kh432jk4h32jkh43jk2h4jk32h4jk23h4jk34hkj32h4jk32h4j32kh4
and the crypto key itself is also stored in session.

> I store quite a bit of state in the HTTP session in my Tapestry
> implementation now. I am not happy with the information in the URLs,
> personally. Would Wicket help me out here?

wicket provides a framework that manages state for you. the advantage
of this is that wicket knows the "scope/lifecycle" of this
information. in your app when you stick something into session when do
you clear it? probably never, so that information pollutes your
session for its duration. wicket knows when to evict information from
session which is a much more optimal usage.

> 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?

no, this is quiet a common usecase

> Honesty - I believe computers/memory/storage is becoming cheaper and that
> ramping up servers which allow less users to run because an application is
> not stateful is an investment I am willing to make - IF it means a cut in
> cost of development, and stability of the application is better, including
> testing, etc. With the money I save in development I can buy more servers.

see my previous email. because wicket offers a true OOP approach it
scales much better across a dev team.

> Myself and my partner are almost certain to switch to Wicket and away from
> Tapestry. Its all about cost. And we are building a web application with
> only our own money, no investment, and we have absolute faith that it will
> have a lot of users according to our business plan. This decision is an
> important one for us. Obviously having no investment means I can switch to a
> framework and do a rewrite if I want to (now), but obviously long term I
> want to stay with my choice.

the sources are all there for you to see from wicket 1.0 to 1.1 to 1.2
to 1.3 to current 1.4 milestone, as are migration paths outlined on
the wiki for each one of those changes. dont know if we have migration
docs from 1.0 to 1.2, that was a long time ago.

-igor

>
> Please - any further comments would be welcome.
>
> Appreciate your time, Graeme.
>
>
> igor.vaynberg wrote:
>>
>> state is always a "scarry" thing for users coming from a stateless
>> framework, but really its a myth. you can find plenty of threads in
>> the archives of this list on this topic. thoof.com used wicket and it
>> received as much traffic as digg at some ponts. too bad they ran out
>> of money because it was a great example of a public wicket app that
>> was under a huge load.
>>
>> the only way for you to measure this is to create a prototype that has
>> a couple of fairly complex pages representative of your application,
>> deploy it into a clustered environment, hammer it, and gather some
>> stats.
>>
>> wicket also has a few extension points which allow you to manually
>> optimize state per page or per component, but those are only used in
>> extreme circumstances.
>>
>> what state does get you is a much better programming model so you can
>> develop your project much faster then in restful frameworks. wicket
>> projects also scale very well across large dev teams.
>>
>> as far as backwards compatibility across releases, we believe in
>> evolutionary approach rather then revolutionary. we do break the api
>> across major releases, but because the core concepts of wicket are
>> very stable the api breaks tend to be fairly easy to fix.
>>
>> i used to develop in t3 and t4 before wicket. what made me switch,
>> among the good old api breaks, was:
>>
>> wicket offers true encapsulation in components
>>
>> form processing is much better then rewinding crap in tapestry which
>> makes it very difficult to do anything outside the box for complex
>> forms
>>
>> and most importantly, wicket's component hierarchy is completely
>> dynamic. you can insert, remove, replace components at any point.
>> tapestry's component hierarchy is static, once the page is built its
>> hard to change its representation. blocks do make some changes
>> possible, but very limiting. consider this: in wicket you can build
>> your entire application as a single page simply swapping parts for
>> navigation.
>>
>> i quit using tapestry before it had ajax support so i cant really
>> comment on it. what i can comment out is that wicket's ajax support is
>> fairly transparent, you can do most things without writing javascript,
>> and because ajax responses are rendered on server you dont need to
>> implement logic on the client in js.
>>
>> -igor
>>
>> On Fri, Oct 31, 2008 at 4:55 AM, GK1971 <gr...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Thank you all for your input. Very valuable. I started reading Wicket In
>>> Action last night and I like how the book is written - very much. It has
>>> the
>>> right explanations in the right places. So, I'm becoming convinced to try
>>> it. But I have concerns around the handling of state. I understand this
>>> is
>>> probably where people do have concerns and I know I am not the first to
>>> ask.
>>>
>>> I want to imagine myself in a position where I have a fairly rich web
>>> application that is publically available on the web, where people can
>>> join
>>> by invitation and have a great user experience. All this may take some
>>> state. Everyone talks about the RESTful model these days but I'm not
>>> convinced thats either new or wise all of the time. What it does allow
>>> you
>>> is easy scalability.
>>>
>>> What are the best ways to scale a Wicket built application across
>>> multiple
>>> servers? I'm assuming Layer 7 load balancers. With bigger state stored
>>> (is
>>> that true?) than an average web app that may mean less users concurrently
>>> per server, but of course you can add more servers.
>>>
>>> Does anyone have any experience with this? Has this automatic handling of
>>> state ever been an issue for anyone?
>>>
>>> Thanks, Graeme.
>>>
>>>
>>> Martin Voigt wrote:
>>>>
>>>> while I haven't migrated any big app from tapestry to wicket (but i
>>>> know tapestry nonetheless), the number one reason to do so would be
>>>> (at least for me) this: wicket is driven by usability (from the
>>>> developers pov) and tapestry is driven by technology. while one does
>>>> not exclude the other, wicket's approach is the better one. i've seen
>>>> java web frameworks come and go, and i watched wicket's progress for
>>>> ages now, and wicket still get's easier to use with each version while
>>>> advancing in terms of technology where it makes sense.
>>>>
>>>> and for the concern about scalability, wicket goes the easy road: more
>>>> load? add some servers and go with the standard apache plus mod-jk
>>>> session sticky thingy or whatever is you load balancer of choice.
>>>>
>>>> but the main reason still would be the developer-friendliness of
>>>> wicket, cos most things are too easy to believe, i18n for example, or
>>>> the serving of error pages. I'm not writing this because I get
>>>> something from promoting wicket, but I did several projects migrating
>>>> to wicket or using it from scratch, and it really delivers what it
>>>> promises.  it made me like java again ;)
>>>>
>>>> Regardsm
>>>> Martin
>>>>
>>>>
>>>> 2008/10/30 GK1971 <gr...@gmail.com>:
>>>>>
>>>>> Hi.
>>>>>
>>>>> You are possibly correct. My main concern is that I have to upgrade
>>>>> from
>>>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>>>>> the
>>>>> least I have allowed myself to look at the options.
>>>>>
>>>>> I guess I am really asking for reasons to move from Tapestry to Wicket
>>>>> -
>>>>> particularlu if anyone has any experience of doing this which they
>>>>> could
>>>>> share. What were those reasons, and pros/cons after sampling both
>>>>> solutions.
>>>>>
>>>>> Thanks for pointing out that I was not clear.
>>>>>
>>>>>
>>>>> Daniel Frisk wrote:
>>>>>>
>>>>>> I actually read your mail but I didn't quite get it, what is your main
>>>>>> concern?
>>>>>> It seems to me like Wicket would be a perfect fit to your four
>>>>>> criteria.
>>>>>>
>>>>>> // Daniel
>>>>>> jalbum.net
>>>>>>
>>>>>>
>>>>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi. I hope this email is appropriate for the forum - its my first
>>>>>>> time
>>>>>>> posting.
>>>>>>>
>>>>>>> My partner and I are in the process of working on a site that
>>>>>>> currently uses
>>>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>>>>> horizontally
>>>>>>> covered in a road map). I am looking around at technologies that we
>>>>>>> can
>>>>>>> pursue in the future that will provide us with a way of creating a
>>>>>>> wonderful
>>>>>>> experience for a user based on dynamic content with Java as a base
>>>>>>> language.
>>>>>>>
>>>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>>>>> Tapestry 5 was still early a year ago when we started the project I
>>>>>>> decided
>>>>>>> to work with Tapestry 4 an understand that once the site was up and
>>>>>>> running
>>>>>>> we may look at rewriting the web layer in an updated framework,
>>>>>>> using the
>>>>>>> lessons we had learned along the way about our specific application.
>>>>>>>
>>>>>>> I have grown unhappy with Tapestry generally - for example, its
>>>>>>> clumsy
>>>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>>>>> application
>>>>>>> which is incredibly complex and inefficient, also. I'm not certain
>>>>>>> its
>>>>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>>>>> productivity point
>>>>>>> of view (maintenance). Debugging a Tapestry application can be
>>>>>>> difficult.
>>>>>>>
>>>>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>>>>> I also
>>>>>>> looked into other frameworks, and short of writing something myself
>>>>>>> I have
>>>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>>>>
>>>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>>>>> ideas I
>>>>>>> have.
>>>>>>>
>>>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>>>>> fix
>>>>>>> myself and that has limited productivity. I would like to write an
>>>>>>> AJAX
>>>>>>> library for myself and hook it into Wicket somehow. Would this be
>>>>>>> possible.
>>>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>>>>> such a
>>>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>>>>> write
>>>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>>>>> understand
>>>>>>> Wicket has a good framework for AJAX but if I require to implement
>>>>>>> code of
>>>>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>>>>> very hard).
>>>>>>>
>>>>>>> Many forums have mentioned scalability is an issue, but I believe
>>>>>>> that this
>>>>>>> is down to an applications individual handling of state rather than
>>>>>>> the
>>>>>>> framework. Am I correct? I am not so worried about this vertical
>>>>>>> scaling as
>>>>>>> long as I can horizontally scale my application on many servers
>>>>>>> (which I can
>>>>>>> if I control state).
>>>>>>>
>>>>>>> What's the road map for Wicket? I understand it is now one of the
>>>>>>> main
>>>>>>> Apache projects (which is one reason I am looking at it), so I
>>>>>>> assume it
>>>>>>> won't disappear sometime next year after I have invested time and
>>>>>>> effort
>>>>>>> into developing with it.
>>>>>>>
>>>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>>>>> other users
>>>>>>> by making future versions so ridiculously incompatible I have to
>>>>>>> rewrite my
>>>>>>> project again?
>>>>>>>
>>>>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>>>>
>>>>>>> 1) Utilize HTML templates (which you do, I understand).
>>>>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>>>>> 3) Utilize Javascript (which I assume you do).
>>>>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>>>>> lightweight but rich user experience for my users (which I guess you
>>>>>>> do).
>>>>>>>
>>>>>>> I have just purchased Wicket in Action so as I can do some research,
>>>>>>> but I
>>>>>>> do appreciate your time if possible.
>>>>>>>
>>>>>>> Many thanks for your help, and your help.
>>>>>>>
>>>>>>> Regards, Graeme.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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--tp20254394p20254748.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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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--tp20254394p20264444.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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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--tp20254394p20271517.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
>
>

---------------------------------------------------------------------
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 guys,

I think the responses alone are almost swaying me toward Wicket - I sense a
strong community. That has been a problem for my in other frameworks where
there is no sense of community and input is not welcome.

Concerning state: My web application really is an application, rather than a
simple stateless site. Developing it using a restful model will mean (I
assume) exposing information about the internals to the client. I don't want
to do this if I can help it - we are so secure that we run using a SSL cert.
I store quite a bit of state in the HTTP session in my Tapestry
implementation now. I am not happy with the information in the URLs,
personally. Would Wicket help me out here?

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? 

Honesty - I believe computers/memory/storage is becoming cheaper and that
ramping up servers which allow less users to run because an application is
not stateful is an investment I am willing to make - IF it means a cut in
cost of development, and stability of the application is better, including
testing, etc. With the money I save in development I can buy more servers. 

Myself and my partner are almost certain to switch to Wicket and away from
Tapestry. Its all about cost. And we are building a web application with
only our own money, no investment, and we have absolute faith that it will
have a lot of users according to our business plan. This decision is an
important one for us. Obviously having no investment means I can switch to a
framework and do a rewrite if I want to (now), but obviously long term I
want to stay with my choice.

Please - any further comments would be welcome.

Appreciate your time, Graeme.


igor.vaynberg wrote:
> 
> state is always a "scarry" thing for users coming from a stateless
> framework, but really its a myth. you can find plenty of threads in
> the archives of this list on this topic. thoof.com used wicket and it
> received as much traffic as digg at some ponts. too bad they ran out
> of money because it was a great example of a public wicket app that
> was under a huge load.
> 
> the only way for you to measure this is to create a prototype that has
> a couple of fairly complex pages representative of your application,
> deploy it into a clustered environment, hammer it, and gather some
> stats.
> 
> wicket also has a few extension points which allow you to manually
> optimize state per page or per component, but those are only used in
> extreme circumstances.
> 
> what state does get you is a much better programming model so you can
> develop your project much faster then in restful frameworks. wicket
> projects also scale very well across large dev teams.
> 
> as far as backwards compatibility across releases, we believe in
> evolutionary approach rather then revolutionary. we do break the api
> across major releases, but because the core concepts of wicket are
> very stable the api breaks tend to be fairly easy to fix.
> 
> i used to develop in t3 and t4 before wicket. what made me switch,
> among the good old api breaks, was:
> 
> wicket offers true encapsulation in components
> 
> form processing is much better then rewinding crap in tapestry which
> makes it very difficult to do anything outside the box for complex
> forms
> 
> and most importantly, wicket's component hierarchy is completely
> dynamic. you can insert, remove, replace components at any point.
> tapestry's component hierarchy is static, once the page is built its
> hard to change its representation. blocks do make some changes
> possible, but very limiting. consider this: in wicket you can build
> your entire application as a single page simply swapping parts for
> navigation.
> 
> i quit using tapestry before it had ajax support so i cant really
> comment on it. what i can comment out is that wicket's ajax support is
> fairly transparent, you can do most things without writing javascript,
> and because ajax responses are rendered on server you dont need to
> implement logic on the client in js.
> 
> -igor
> 
> On Fri, Oct 31, 2008 at 4:55 AM, GK1971 <gr...@gmail.com> wrote:
>>
>> Hi.
>>
>> Thank you all for your input. Very valuable. I started reading Wicket In
>> Action last night and I like how the book is written - very much. It has
>> the
>> right explanations in the right places. So, I'm becoming convinced to try
>> it. But I have concerns around the handling of state. I understand this
>> is
>> probably where people do have concerns and I know I am not the first to
>> ask.
>>
>> I want to imagine myself in a position where I have a fairly rich web
>> application that is publically available on the web, where people can
>> join
>> by invitation and have a great user experience. All this may take some
>> state. Everyone talks about the RESTful model these days but I'm not
>> convinced thats either new or wise all of the time. What it does allow
>> you
>> is easy scalability.
>>
>> What are the best ways to scale a Wicket built application across
>> multiple
>> servers? I'm assuming Layer 7 load balancers. With bigger state stored
>> (is
>> that true?) than an average web app that may mean less users concurrently
>> per server, but of course you can add more servers.
>>
>> Does anyone have any experience with this? Has this automatic handling of
>> state ever been an issue for anyone?
>>
>> Thanks, Graeme.
>>
>>
>> Martin Voigt wrote:
>>>
>>> while I haven't migrated any big app from tapestry to wicket (but i
>>> know tapestry nonetheless), the number one reason to do so would be
>>> (at least for me) this: wicket is driven by usability (from the
>>> developers pov) and tapestry is driven by technology. while one does
>>> not exclude the other, wicket's approach is the better one. i've seen
>>> java web frameworks come and go, and i watched wicket's progress for
>>> ages now, and wicket still get's easier to use with each version while
>>> advancing in terms of technology where it makes sense.
>>>
>>> and for the concern about scalability, wicket goes the easy road: more
>>> load? add some servers and go with the standard apache plus mod-jk
>>> session sticky thingy or whatever is you load balancer of choice.
>>>
>>> but the main reason still would be the developer-friendliness of
>>> wicket, cos most things are too easy to believe, i18n for example, or
>>> the serving of error pages. I'm not writing this because I get
>>> something from promoting wicket, but I did several projects migrating
>>> to wicket or using it from scratch, and it really delivers what it
>>> promises.  it made me like java again ;)
>>>
>>> Regardsm
>>> Martin
>>>
>>>
>>> 2008/10/30 GK1971 <gr...@gmail.com>:
>>>>
>>>> Hi.
>>>>
>>>> You are possibly correct. My main concern is that I have to upgrade
>>>> from
>>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>>>> the
>>>> least I have allowed myself to look at the options.
>>>>
>>>> I guess I am really asking for reasons to move from Tapestry to Wicket
>>>> -
>>>> particularlu if anyone has any experience of doing this which they
>>>> could
>>>> share. What were those reasons, and pros/cons after sampling both
>>>> solutions.
>>>>
>>>> Thanks for pointing out that I was not clear.
>>>>
>>>>
>>>> Daniel Frisk wrote:
>>>>>
>>>>> I actually read your mail but I didn't quite get it, what is your main
>>>>> concern?
>>>>> It seems to me like Wicket would be a perfect fit to your four
>>>>> criteria.
>>>>>
>>>>> // Daniel
>>>>> jalbum.net
>>>>>
>>>>>
>>>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>>>
>>>>>>
>>>>>> Hi. I hope this email is appropriate for the forum - its my first
>>>>>> time
>>>>>> posting.
>>>>>>
>>>>>> My partner and I are in the process of working on a site that
>>>>>> currently uses
>>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>>>> horizontally
>>>>>> covered in a road map). I am looking around at technologies that we
>>>>>> can
>>>>>> pursue in the future that will provide us with a way of creating a
>>>>>> wonderful
>>>>>> experience for a user based on dynamic content with Java as a base
>>>>>> language.
>>>>>>
>>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>>>> Tapestry 5 was still early a year ago when we started the project I
>>>>>> decided
>>>>>> to work with Tapestry 4 an understand that once the site was up and
>>>>>> running
>>>>>> we may look at rewriting the web layer in an updated framework,
>>>>>> using the
>>>>>> lessons we had learned along the way about our specific application.
>>>>>>
>>>>>> I have grown unhappy with Tapestry generally - for example, its
>>>>>> clumsy
>>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>>>> application
>>>>>> which is incredibly complex and inefficient, also. I'm not certain
>>>>>> its
>>>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>>>> productivity point
>>>>>> of view (maintenance). Debugging a Tapestry application can be
>>>>>> difficult.
>>>>>>
>>>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>>>> I also
>>>>>> looked into other frameworks, and short of writing something myself
>>>>>> I have
>>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>>>
>>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>>>> ideas I
>>>>>> have.
>>>>>>
>>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>>>> fix
>>>>>> myself and that has limited productivity. I would like to write an
>>>>>> AJAX
>>>>>> library for myself and hook it into Wicket somehow. Would this be
>>>>>> possible.
>>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>>>> such a
>>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>>>> write
>>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>>>> understand
>>>>>> Wicket has a good framework for AJAX but if I require to implement
>>>>>> code of
>>>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>>>> very hard).
>>>>>>
>>>>>> Many forums have mentioned scalability is an issue, but I believe
>>>>>> that this
>>>>>> is down to an applications individual handling of state rather than
>>>>>> the
>>>>>> framework. Am I correct? I am not so worried about this vertical
>>>>>> scaling as
>>>>>> long as I can horizontally scale my application on many servers
>>>>>> (which I can
>>>>>> if I control state).
>>>>>>
>>>>>> What's the road map for Wicket? I understand it is now one of the
>>>>>> main
>>>>>> Apache projects (which is one reason I am looking at it), so I
>>>>>> assume it
>>>>>> won't disappear sometime next year after I have invested time and
>>>>>> effort
>>>>>> into developing with it.
>>>>>>
>>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>>>> other users
>>>>>> by making future versions so ridiculously incompatible I have to
>>>>>> rewrite my
>>>>>> project again?
>>>>>>
>>>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>>>
>>>>>> 1) Utilize HTML templates (which you do, I understand).
>>>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>>>> 3) Utilize Javascript (which I assume you do).
>>>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>>>> lightweight but rich user experience for my users (which I guess you
>>>>>> do).
>>>>>>
>>>>>> I have just purchased Wicket in Action so as I can do some research,
>>>>>> but I
>>>>>> do appreciate your time if possible.
>>>>>>
>>>>>> Many thanks for your help, and your help.
>>>>>>
>>>>>> Regards, Graeme.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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--tp20254394p20254748.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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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--tp20254394p20264444.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
>>
>>
> 
> ---------------------------------------------------------------------
> 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--tp20254394p20271517.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?

[Igor Vaynberg <ig...@gmail.com>]

state is always a "scarry" thing for users coming from a stateless
framework, but really its a myth. you can find plenty of threads in
the archives of this list on this topic. thoof.com used wicket and it
received as much traffic as digg at some ponts. too bad they ran out
of money because it was a great example of a public wicket app that
was under a huge load.

the only way for you to measure this is to create a prototype that has
a couple of fairly complex pages representative of your application,
deploy it into a clustered environment, hammer it, and gather some
stats.

wicket also has a few extension points which allow you to manually
optimize state per page or per component, but those are only used in
extreme circumstances.

what state does get you is a much better programming model so you can
develop your project much faster then in restful frameworks. wicket
projects also scale very well across large dev teams.

as far as backwards compatibility across releases, we believe in
evolutionary approach rather then revolutionary. we do break the api
across major releases, but because the core concepts of wicket are
very stable the api breaks tend to be fairly easy to fix.

i used to develop in t3 and t4 before wicket. what made me switch,
among the good old api breaks, was:

wicket offers true encapsulation in components

form processing is much better then rewinding crap in tapestry which
makes it very difficult to do anything outside the box for complex
forms

and most importantly, wicket's component hierarchy is completely
dynamic. you can insert, remove, replace components at any point.
tapestry's component hierarchy is static, once the page is built its
hard to change its representation. blocks do make some changes
possible, but very limiting. consider this: in wicket you can build
your entire application as a single page simply swapping parts for
navigation.

i quit using tapestry before it had ajax support so i cant really
comment on it. what i can comment out is that wicket's ajax support is
fairly transparent, you can do most things without writing javascript,
and because ajax responses are rendered on server you dont need to
implement logic on the client in js.

-igor

On Fri, Oct 31, 2008 at 4:55 AM, GK1971 <gr...@gmail.com> wrote:
>
> Hi.
>
> Thank you all for your input. Very valuable. I started reading Wicket In
> Action last night and I like how the book is written - very much. It has the
> right explanations in the right places. So, I'm becoming convinced to try
> it. But I have concerns around the handling of state. I understand this is
> probably where people do have concerns and I know I am not the first to ask.
>
> I want to imagine myself in a position where I have a fairly rich web
> application that is publically available on the web, where people can join
> by invitation and have a great user experience. All this may take some
> state. Everyone talks about the RESTful model these days but I'm not
> convinced thats either new or wise all of the time. What it does allow you
> is easy scalability.
>
> What are the best ways to scale a Wicket built application across multiple
> servers? I'm assuming Layer 7 load balancers. With bigger state stored (is
> that true?) than an average web app that may mean less users concurrently
> per server, but of course you can add more servers.
>
> Does anyone have any experience with this? Has this automatic handling of
> state ever been an issue for anyone?
>
> Thanks, Graeme.
>
>
> Martin Voigt wrote:
>>
>> while I haven't migrated any big app from tapestry to wicket (but i
>> know tapestry nonetheless), the number one reason to do so would be
>> (at least for me) this: wicket is driven by usability (from the
>> developers pov) and tapestry is driven by technology. while one does
>> not exclude the other, wicket's approach is the better one. i've seen
>> java web frameworks come and go, and i watched wicket's progress for
>> ages now, and wicket still get's easier to use with each version while
>> advancing in terms of technology where it makes sense.
>>
>> and for the concern about scalability, wicket goes the easy road: more
>> load? add some servers and go with the standard apache plus mod-jk
>> session sticky thingy or whatever is you load balancer of choice.
>>
>> but the main reason still would be the developer-friendliness of
>> wicket, cos most things are too easy to believe, i18n for example, or
>> the serving of error pages. I'm not writing this because I get
>> something from promoting wicket, but I did several projects migrating
>> to wicket or using it from scratch, and it really delivers what it
>> promises.  it made me like java again ;)
>>
>> Regardsm
>> Martin
>>
>>
>> 2008/10/30 GK1971 <gr...@gmail.com>:
>>>
>>> Hi.
>>>
>>> You are possibly correct. My main concern is that I have to upgrade from
>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>>> the
>>> least I have allowed myself to look at the options.
>>>
>>> I guess I am really asking for reasons to move from Tapestry to Wicket -
>>> particularlu if anyone has any experience of doing this which they could
>>> share. What were those reasons, and pros/cons after sampling both
>>> solutions.
>>>
>>> Thanks for pointing out that I was not clear.
>>>
>>>
>>> Daniel Frisk wrote:
>>>>
>>>> I actually read your mail but I didn't quite get it, what is your main
>>>> concern?
>>>> It seems to me like Wicket would be a perfect fit to your four criteria.
>>>>
>>>> // Daniel
>>>> jalbum.net
>>>>
>>>>
>>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>>
>>>>>
>>>>> Hi. I hope this email is appropriate for the forum - its my first time
>>>>> posting.
>>>>>
>>>>> My partner and I are in the process of working on a site that
>>>>> currently uses
>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>>> horizontally
>>>>> covered in a road map). I am looking around at technologies that we
>>>>> can
>>>>> pursue in the future that will provide us with a way of creating a
>>>>> wonderful
>>>>> experience for a user based on dynamic content with Java as a base
>>>>> language.
>>>>>
>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>>> Tapestry 5 was still early a year ago when we started the project I
>>>>> decided
>>>>> to work with Tapestry 4 an understand that once the site was up and
>>>>> running
>>>>> we may look at rewriting the web layer in an updated framework,
>>>>> using the
>>>>> lessons we had learned along the way about our specific application.
>>>>>
>>>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>>> application
>>>>> which is incredibly complex and inefficient, also. I'm not certain its
>>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>>> productivity point
>>>>> of view (maintenance). Debugging a Tapestry application can be
>>>>> difficult.
>>>>>
>>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>>> I also
>>>>> looked into other frameworks, and short of writing something myself
>>>>> I have
>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>>
>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>>> ideas I
>>>>> have.
>>>>>
>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>>> fix
>>>>> myself and that has limited productivity. I would like to write an
>>>>> AJAX
>>>>> library for myself and hook it into Wicket somehow. Would this be
>>>>> possible.
>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>>> such a
>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>>> write
>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>>> understand
>>>>> Wicket has a good framework for AJAX but if I require to implement
>>>>> code of
>>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>>> very hard).
>>>>>
>>>>> Many forums have mentioned scalability is an issue, but I believe
>>>>> that this
>>>>> is down to an applications individual handling of state rather than
>>>>> the
>>>>> framework. Am I correct? I am not so worried about this vertical
>>>>> scaling as
>>>>> long as I can horizontally scale my application on many servers
>>>>> (which I can
>>>>> if I control state).
>>>>>
>>>>> What's the road map for Wicket? I understand it is now one of the main
>>>>> Apache projects (which is one reason I am looking at it), so I
>>>>> assume it
>>>>> won't disappear sometime next year after I have invested time and
>>>>> effort
>>>>> into developing with it.
>>>>>
>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>>> other users
>>>>> by making future versions so ridiculously incompatible I have to
>>>>> rewrite my
>>>>> project again?
>>>>>
>>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>>
>>>>> 1) Utilize HTML templates (which you do, I understand).
>>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>>> 3) Utilize Javascript (which I assume you do).
>>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>>> lightweight but rich user experience for my users (which I guess you
>>>>> do).
>>>>>
>>>>> I have just purchased Wicket in Action so as I can do some research,
>>>>> but I
>>>>> do appreciate your time if possible.
>>>>>
>>>>> Many thanks for your help, and your help.
>>>>>
>>>>> Regards, Graeme.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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--tp20254394p20254748.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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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--tp20254394p20264444.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
>
>

---------------------------------------------------------------------
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?

[Scott Swank <sc...@gmail.com>]

Regarding session state, you really have basic options.  State is kept
in implementations of IModel.

1. Model is just a holder for an object.  If you use it then your
object is in your session.
2. LoadableDetachableModel stores an id (or whatever) and retrieves
the relevant object from your repository.

So you're back to the basic tradeoff: memory vs. i/o.

Scott


On Fri, Oct 31, 2008 at 5:02 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> Regarding scalability. If you stick to using loadable detachable models and
> use terracotta, I've heard thats a good option?
>
>
> And no defiantly the automatic handling of state are have never been a
> problem for me, you just need to remember that things can be serialized at
> times, but the serializable checker will remind you if somethings not
> serializable, and then you have a heads up.
>
> GK1971 wrote:
>>
>> Hi.
>>
>> Thank you all for your input. Very valuable. I started reading Wicket In
>> Action last night and I like how the book is written - very much. It has
>> the
>> right explanations in the right places. So, I'm becoming convinced to try
>> it. But I have concerns around the handling of state. I understand this is
>> probably where people do have concerns and I know I am not the first to
>> ask.
>>
>> I want to imagine myself in a position where I have a fairly rich web
>> application that is publically available on the web, where people can join
>> by invitation and have a great user experience. All this may take some
>> state. Everyone talks about the RESTful model these days but I'm not
>> convinced thats either new or wise all of the time. What it does allow you
>> is easy scalability.
>>
>> What are the best ways to scale a Wicket built application across multiple
>> servers? I'm assuming Layer 7 load balancers. With bigger state stored (is
>> that true?) than an average web app that may mean less users concurrently
>> per server, but of course you can add more servers.
>>
>> Does anyone have any experience with this? Has this automatic handling of
>> state ever been an issue for anyone?
>> Thanks, Graeme.
>>
>>
>> Martin Voigt wrote:
>>
>>>
>>> while I haven't migrated any big app from tapestry to wicket (but i
>>> know tapestry nonetheless), the number one reason to do so would be
>>> (at least for me) this: wicket is driven by usability (from the
>>> developers pov) and tapestry is driven by technology. while one does
>>> not exclude the other, wicket's approach is the better one. i've seen
>>> java web frameworks come and go, and i watched wicket's progress for
>>> ages now, and wicket still get's easier to use with each version while
>>> advancing in terms of technology where it makes sense.
>>>
>>> and for the concern about scalability, wicket goes the easy road: more
>>> load? add some servers and go with the standard apache plus mod-jk
>>> session sticky thingy or whatever is you load balancer of choice.
>>>
>>> but the main reason still would be the developer-friendliness of
>>> wicket, cos most things are too easy to believe, i18n for example, or
>>> the serving of error pages. I'm not writing this because I get
>>> something from promoting wicket, but I did several projects migrating
>>> to wicket or using it from scratch, and it really delivers what it
>>> promises.  it made me like java again ;)
>>>
>>> Regardsm
>>> Martin
>>>
>>>
>>> 2008/10/30 GK1971 <gr...@gmail.com>:
>>>
>>>>
>>>> Hi.
>>>>
>>>> You are possibly correct. My main concern is that I have to upgrade from
>>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>>>> the
>>>> least I have allowed myself to look at the options.
>>>>
>>>> I guess I am really asking for reasons to move from Tapestry to Wicket -
>>>> particularlu if anyone has any experience of doing this which they could
>>>> share. What were those reasons, and pros/cons after sampling both
>>>> solutions.
>>>>
>>>> Thanks for pointing out that I was not clear.
>>>>
>>>>
>>>> Daniel Frisk wrote:
>>>>
>>>>>
>>>>> I actually read your mail but I didn't quite get it, what is your main
>>>>> concern?
>>>>> It seems to me like Wicket would be a perfect fit to your four
>>>>> criteria.
>>>>>
>>>>> // Daniel
>>>>> jalbum.net
>>>>>
>>>>>
>>>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Hi. I hope this email is appropriate for the forum - its my first time
>>>>>> posting.
>>>>>>
>>>>>> My partner and I are in the process of working on a site that
>>>>>> currently uses
>>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>>>> horizontally
>>>>>> covered in a road map). I am looking around at technologies that we
>>>>>> can
>>>>>> pursue in the future that will provide us with a way of creating a
>>>>>> wonderful
>>>>>> experience for a user based on dynamic content with Java as a base
>>>>>> language.
>>>>>>
>>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>>>> Tapestry 5 was still early a year ago when we started the project I
>>>>>> decided
>>>>>> to work with Tapestry 4 an understand that once the site was up and
>>>>>> running
>>>>>> we may look at rewriting the web layer in an updated framework,
>>>>>> using the
>>>>>> lessons we had learned along the way about our specific application.
>>>>>>
>>>>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>>>> application
>>>>>> which is incredibly complex and inefficient, also. I'm not certain its
>>>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>>>> productivity point
>>>>>> of view (maintenance). Debugging a Tapestry application can be
>>>>>> difficult.
>>>>>>
>>>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>>>> I also
>>>>>> looked into other frameworks, and short of writing something myself
>>>>>> I have
>>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>>>
>>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>>>> ideas I
>>>>>> have.
>>>>>>
>>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>>>> fix
>>>>>> myself and that has limited productivity. I would like to write an
>>>>>> AJAX
>>>>>> library for myself and hook it into Wicket somehow. Would this be
>>>>>> possible.
>>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>>>> such a
>>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>>>> write
>>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>>>> understand
>>>>>> Wicket has a good framework for AJAX but if I require to implement
>>>>>> code of
>>>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>>>> very hard).
>>>>>>
>>>>>> Many forums have mentioned scalability is an issue, but I believe
>>>>>> that this
>>>>>> is down to an applications individual handling of state rather than
>>>>>> the
>>>>>> framework. Am I correct? I am not so worried about this vertical
>>>>>> scaling as
>>>>>> long as I can horizontally scale my application on many servers
>>>>>> (which I can
>>>>>> if I control state).
>>>>>>
>>>>>> What's the road map for Wicket? I understand it is now one of the main
>>>>>> Apache projects (which is one reason I am looking at it), so I
>>>>>> assume it
>>>>>> won't disappear sometime next year after I have invested time and
>>>>>> effort
>>>>>> into developing with it.
>>>>>>
>>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>>>> other users
>>>>>> by making future versions so ridiculously incompatible I have to
>>>>>> rewrite my
>>>>>> project again?
>>>>>>
>>>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>>>
>>>>>> 1) Utilize HTML templates (which you do, I understand).
>>>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>>>> 3) Utilize Javascript (which I assume you do).
>>>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>>>> lightweight but rich user experience for my users (which I guess you
>>>>>> do).
>>>>>>
>>>>>> I have just purchased Wicket in Action so as I can do some research,
>>>>>> but I
>>>>>> do appreciate your time if possible.
>>>>>>
>>>>>> Many thanks for your help, and your help.
>>>>>>
>>>>>> Regards, Graeme.
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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--tp20254394p20254748.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
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> 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: Moving from Tapestry to Wicket?

[Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>]

Regarding scalability. If you stick to using loadable detachable models 
and use terracotta, I've heard thats a good option?


And no defiantly the automatic handling of state are have never been a 
problem for me, you just need to remember that things can be serialized 
at times, but the serializable checker will remind you if somethings not 
serializable, and then you have a heads up.

GK1971 wrote:
> Hi.
>
> Thank you all for your input. Very valuable. I started reading Wicket In
> Action last night and I like how the book is written - very much. It has the
> right explanations in the right places. So, I'm becoming convinced to try
> it. But I have concerns around the handling of state. I understand this is
> probably where people do have concerns and I know I am not the first to ask.
>
> I want to imagine myself in a position where I have a fairly rich web
> application that is publically available on the web, where people can join
> by invitation and have a great user experience. All this may take some
> state. Everyone talks about the RESTful model these days but I'm not
> convinced thats either new or wise all of the time. What it does allow you
> is easy scalability.
>
> What are the best ways to scale a Wicket built application across multiple
> servers? I'm assuming Layer 7 load balancers. With bigger state stored (is
> that true?) than an average web app that may mean less users concurrently
> per server, but of course you can add more servers.
>
> Does anyone have any experience with this? Has this automatic handling of
> state ever been an issue for anyone? 
>
> Thanks, Graeme.
>
>
> Martin Voigt wrote:
>   
>> while I haven't migrated any big app from tapestry to wicket (but i
>> know tapestry nonetheless), the number one reason to do so would be
>> (at least for me) this: wicket is driven by usability (from the
>> developers pov) and tapestry is driven by technology. while one does
>> not exclude the other, wicket's approach is the better one. i've seen
>> java web frameworks come and go, and i watched wicket's progress for
>> ages now, and wicket still get's easier to use with each version while
>> advancing in terms of technology where it makes sense.
>>
>> and for the concern about scalability, wicket goes the easy road: more
>> load? add some servers and go with the standard apache plus mod-jk
>> session sticky thingy or whatever is you load balancer of choice.
>>
>> but the main reason still would be the developer-friendliness of
>> wicket, cos most things are too easy to believe, i18n for example, or
>> the serving of error pages. I'm not writing this because I get
>> something from promoting wicket, but I did several projects migrating
>> to wicket or using it from scratch, and it really delivers what it
>> promises.  it made me like java again ;)
>>
>> Regardsm
>> Martin
>>
>>
>> 2008/10/30 GK1971 <gr...@gmail.com>:
>>     
>>> Hi.
>>>
>>> You are possibly correct. My main concern is that I have to upgrade from
>>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>>> the
>>> least I have allowed myself to look at the options.
>>>
>>> I guess I am really asking for reasons to move from Tapestry to Wicket -
>>> particularlu if anyone has any experience of doing this which they could
>>> share. What were those reasons, and pros/cons after sampling both
>>> solutions.
>>>
>>> Thanks for pointing out that I was not clear.
>>>
>>>
>>> Daniel Frisk wrote:
>>>       
>>>> I actually read your mail but I didn't quite get it, what is your main
>>>> concern?
>>>> It seems to me like Wicket would be a perfect fit to your four criteria.
>>>>
>>>> // Daniel
>>>> jalbum.net
>>>>
>>>>
>>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>>
>>>>         
>>>>> Hi. I hope this email is appropriate for the forum - its my first time
>>>>> posting.
>>>>>
>>>>> My partner and I are in the process of working on a site that
>>>>> currently uses
>>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>>> horizontally
>>>>> covered in a road map). I am looking around at technologies that we
>>>>> can
>>>>> pursue in the future that will provide us with a way of creating a
>>>>> wonderful
>>>>> experience for a user based on dynamic content with Java as a base
>>>>> language.
>>>>>
>>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>>> Tapestry 5 was still early a year ago when we started the project I
>>>>> decided
>>>>> to work with Tapestry 4 an understand that once the site was up and
>>>>> running
>>>>> we may look at rewriting the web layer in an updated framework,
>>>>> using the
>>>>> lessons we had learned along the way about our specific application.
>>>>>
>>>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>>> application
>>>>> which is incredibly complex and inefficient, also. I'm not certain its
>>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>>> productivity point
>>>>> of view (maintenance). Debugging a Tapestry application can be
>>>>> difficult.
>>>>>
>>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>>> I also
>>>>> looked into other frameworks, and short of writing something myself
>>>>> I have
>>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>>
>>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>>> ideas I
>>>>> have.
>>>>>
>>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>>> fix
>>>>> myself and that has limited productivity. I would like to write an
>>>>> AJAX
>>>>> library for myself and hook it into Wicket somehow. Would this be
>>>>> possible.
>>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>>> such a
>>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>>> write
>>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>>> understand
>>>>> Wicket has a good framework for AJAX but if I require to implement
>>>>> code of
>>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>>> very hard).
>>>>>
>>>>> Many forums have mentioned scalability is an issue, but I believe
>>>>> that this
>>>>> is down to an applications individual handling of state rather than
>>>>> the
>>>>> framework. Am I correct? I am not so worried about this vertical
>>>>> scaling as
>>>>> long as I can horizontally scale my application on many servers
>>>>> (which I can
>>>>> if I control state).
>>>>>
>>>>> What's the road map for Wicket? I understand it is now one of the main
>>>>> Apache projects (which is one reason I am looking at it), so I
>>>>> assume it
>>>>> won't disappear sometime next year after I have invested time and
>>>>> effort
>>>>> into developing with it.
>>>>>
>>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>>> other users
>>>>> by making future versions so ridiculously incompatible I have to
>>>>> rewrite my
>>>>> project again?
>>>>>
>>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>>
>>>>> 1) Utilize HTML templates (which you do, I understand).
>>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>>> 3) Utilize Javascript (which I assume you do).
>>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>>> lightweight but rich user experience for my users (which I guess you
>>>>> do).
>>>>>
>>>>> I have just purchased Wicket in Action so as I can do some research,
>>>>> but I
>>>>> do appreciate your time if possible.
>>>>>
>>>>> Many thanks for your help, and your help.
>>>>>
>>>>> Regards, Graeme.
>>>>>           
>>>> ---------------------------------------------------------------------
>>>> 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--tp20254394p20254748.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
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>     
>
>   

-- 
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


---------------------------------------------------------------------
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.

Thank you all for your input. Very valuable. I started reading Wicket In
Action last night and I like how the book is written - very much. It has the
right explanations in the right places. So, I'm becoming convinced to try
it. But I have concerns around the handling of state. I understand this is
probably where people do have concerns and I know I am not the first to ask.

I want to imagine myself in a position where I have a fairly rich web
application that is publically available on the web, where people can join
by invitation and have a great user experience. All this may take some
state. Everyone talks about the RESTful model these days but I'm not
convinced thats either new or wise all of the time. What it does allow you
is easy scalability.

What are the best ways to scale a Wicket built application across multiple
servers? I'm assuming Layer 7 load balancers. With bigger state stored (is
that true?) than an average web app that may mean less users concurrently
per server, but of course you can add more servers.

Does anyone have any experience with this? Has this automatic handling of
state ever been an issue for anyone? 

Thanks, Graeme.


Martin Voigt wrote:
> 
> while I haven't migrated any big app from tapestry to wicket (but i
> know tapestry nonetheless), the number one reason to do so would be
> (at least for me) this: wicket is driven by usability (from the
> developers pov) and tapestry is driven by technology. while one does
> not exclude the other, wicket's approach is the better one. i've seen
> java web frameworks come and go, and i watched wicket's progress for
> ages now, and wicket still get's easier to use with each version while
> advancing in terms of technology where it makes sense.
> 
> and for the concern about scalability, wicket goes the easy road: more
> load? add some servers and go with the standard apache plus mod-jk
> session sticky thingy or whatever is you load balancer of choice.
> 
> but the main reason still would be the developer-friendliness of
> wicket, cos most things are too easy to believe, i18n for example, or
> the serving of error pages. I'm not writing this because I get
> something from promoting wicket, but I did several projects migrating
> to wicket or using it from scratch, and it really delivers what it
> promises.  it made me like java again ;)
> 
> Regardsm
> Martin
> 
> 
> 2008/10/30 GK1971 <gr...@gmail.com>:
>>
>> Hi.
>>
>> You are possibly correct. My main concern is that I have to upgrade from
>> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
>> the
>> least I have allowed myself to look at the options.
>>
>> I guess I am really asking for reasons to move from Tapestry to Wicket -
>> particularlu if anyone has any experience of doing this which they could
>> share. What were those reasons, and pros/cons after sampling both
>> solutions.
>>
>> Thanks for pointing out that I was not clear.
>>
>>
>> Daniel Frisk wrote:
>>>
>>> I actually read your mail but I didn't quite get it, what is your main
>>> concern?
>>> It seems to me like Wicket would be a perfect fit to your four criteria.
>>>
>>> // Daniel
>>> jalbum.net
>>>
>>>
>>> On 2008-10-30, at 21:05, GK1971 wrote:
>>>
>>>>
>>>> Hi. I hope this email is appropriate for the forum - its my first time
>>>> posting.
>>>>
>>>> My partner and I are in the process of working on a site that
>>>> currently uses
>>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>>> horizontally
>>>> covered in a road map). I am looking around at technologies that we
>>>> can
>>>> pursue in the future that will provide us with a way of creating a
>>>> wonderful
>>>> experience for a user based on dynamic content with Java as a base
>>>> language.
>>>>
>>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>>> Tapestry 5 was still early a year ago when we started the project I
>>>> decided
>>>> to work with Tapestry 4 an understand that once the site was up and
>>>> running
>>>> we may look at rewriting the web layer in an updated framework,
>>>> using the
>>>> lessons we had learned along the way about our specific application.
>>>>
>>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>>> application
>>>> which is incredibly complex and inefficient, also. I'm not certain its
>>>> declarative approach in Tapestry 5 is a wise thing from a
>>>> productivity point
>>>> of view (maintenance). Debugging a Tapestry application can be
>>>> difficult.
>>>>
>>>> I found myself looking at JSF, but we'd like to actually deliver a
>>>> functioning site quickly and not have our hands tied by bureaucracy.
>>>> I also
>>>> looked into other frameworks, and short of writing something myself
>>>> I have
>>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>>
>>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>>> ideas I
>>>> have.
>>>>
>>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>>> fix
>>>> myself and that has limited productivity. I would like to write an
>>>> AJAX
>>>> library for myself and hook it into Wicket somehow. Would this be
>>>> possible.
>>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>>> such a
>>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>>> write
>>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>>> understand
>>>> Wicket has a good framework for AJAX but if I require to implement
>>>> code of
>>>> my own, is it easy to slip under the hood (with Tapestry this is
>>>> very hard).
>>>>
>>>> Many forums have mentioned scalability is an issue, but I believe
>>>> that this
>>>> is down to an applications individual handling of state rather than
>>>> the
>>>> framework. Am I correct? I am not so worried about this vertical
>>>> scaling as
>>>> long as I can horizontally scale my application on many servers
>>>> (which I can
>>>> if I control state).
>>>>
>>>> What's the road map for Wicket? I understand it is now one of the main
>>>> Apache projects (which is one reason I am looking at it), so I
>>>> assume it
>>>> won't disappear sometime next year after I have invested time and
>>>> effort
>>>> into developing with it.
>>>>
>>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>>> other users
>>>> by making future versions so ridiculously incompatible I have to
>>>> rewrite my
>>>> project again?
>>>>
>>>> Honestly, I'm looking for a framework that will allow me to:
>>>>
>>>> 1) Utilize HTML templates (which you do, I understand).
>>>> 2) Utilize CSS (which you do) files externally for my artist.
>>>> 3) Utilize Javascript (which I assume you do).
>>>> 4) Utilize a Java, component based web framework for creating a fast
>>>> lightweight but rich user experience for my users (which I guess you
>>>> do).
>>>>
>>>> I have just purchased Wicket in Action so as I can do some research,
>>>> but I
>>>> do appreciate your time if possible.
>>>>
>>>> Many thanks for your help, and your help.
>>>>
>>>> Regards, Graeme.
>>>
>>> ---------------------------------------------------------------------
>>> 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--tp20254394p20254748.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
>>
>>
> 
> ---------------------------------------------------------------------
> 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--tp20254394p20264444.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?

[Martin Voigt <vo...@googlemail.com>]

while I haven't migrated any big app from tapestry to wicket (but i
know tapestry nonetheless), the number one reason to do so would be
(at least for me) this: wicket is driven by usability (from the
developers pov) and tapestry is driven by technology. while one does
not exclude the other, wicket's approach is the better one. i've seen
java web frameworks come and go, and i watched wicket's progress for
ages now, and wicket still get's easier to use with each version while
advancing in terms of technology where it makes sense.

and for the concern about scalability, wicket goes the easy road: more
load? add some servers and go with the standard apache plus mod-jk
session sticky thingy or whatever is you load balancer of choice.

but the main reason still would be the developer-friendliness of
wicket, cos most things are too easy to believe, i18n for example, or
the serving of error pages. I'm not writing this because I get
something from promoting wicket, but I did several projects migrating
to wicket or using it from scratch, and it really delivers what it
promises.  it made me like java again ;)

Regardsm
Martin


2008/10/30 GK1971 <gr...@gmail.com>:
>
> Hi.
>
> You are possibly correct. My main concern is that I have to upgrade from
> Tapestry 4 to... something. Given that Tapestry 5 is not compatible in the
> least I have allowed myself to look at the options.
>
> I guess I am really asking for reasons to move from Tapestry to Wicket -
> particularlu if anyone has any experience of doing this which they could
> share. What were those reasons, and pros/cons after sampling both solutions.
>
> Thanks for pointing out that I was not clear.
>
>
> Daniel Frisk wrote:
>>
>> I actually read your mail but I didn't quite get it, what is your main
>> concern?
>> It seems to me like Wicket would be a perfect fit to your four criteria.
>>
>> // Daniel
>> jalbum.net
>>
>>
>> On 2008-10-30, at 21:05, GK1971 wrote:
>>
>>>
>>> Hi. I hope this email is appropriate for the forum - its my first time
>>> posting.
>>>
>>> My partner and I are in the process of working on a site that
>>> currently uses
>>> Tapestry 4 and must be reasonably scalable vertically (we have
>>> horizontally
>>> covered in a road map). I am looking around at technologies that we
>>> can
>>> pursue in the future that will provide us with a way of creating a
>>> wonderful
>>> experience for a user based on dynamic content with Java as a base
>>> language.
>>>
>>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>>> Tapestry 5 was still early a year ago when we started the project I
>>> decided
>>> to work with Tapestry 4 an understand that once the site was up and
>>> running
>>> we may look at rewriting the web layer in an updated framework,
>>> using the
>>> lessons we had learned along the way about our specific application.
>>>
>>> I have grown unhappy with Tapestry generally - for example, its clumsy
>>> handling of AJAX. Even a seasoned developer can write a Tapestry
>>> application
>>> which is incredibly complex and inefficient, also. I'm not certain its
>>> declarative approach in Tapestry 5 is a wise thing from a
>>> productivity point
>>> of view (maintenance). Debugging a Tapestry application can be
>>> difficult.
>>>
>>> I found myself looking at JSF, but we'd like to actually deliver a
>>> functioning site quickly and not have our hands tied by bureaucracy.
>>> I also
>>> looked into other frameworks, and short of writing something myself
>>> I have
>>> found the best for our needs to be Tapestry 5 (scares me - what will
>>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>>
>>> I'm liking the look of Wicket but I wondered if it would fill a few
>>> ideas I
>>> have.
>>>
>>> I have had significant issues with DOJO/Tapestry bugs that I cannot
>>> fix
>>> myself and that has limited productivity. I would like to write an
>>> AJAX
>>> library for myself and hook it into Wicket somehow. Would this be
>>> possible.
>>> I feel it may be a pain in Tapestry because there 'appears' to be
>>> such a
>>> high coupling with DOJO now. Would it be conceptually easy for me to
>>> write
>>> Javascript/AJAX and hook them into Wicket in a simple way? I
>>> understand
>>> Wicket has a good framework for AJAX but if I require to implement
>>> code of
>>> my own, is it easy to slip under the hood (with Tapestry this is
>>> very hard).
>>>
>>> Many forums have mentioned scalability is an issue, but I believe
>>> that this
>>> is down to an applications individual handling of state rather than
>>> the
>>> framework. Am I correct? I am not so worried about this vertical
>>> scaling as
>>> long as I can horizontally scale my application on many servers
>>> (which I can
>>> if I control state).
>>>
>>> What's the road map for Wicket? I understand it is now one of the main
>>> Apache projects (which is one reason I am looking at it), so I
>>> assume it
>>> won't disappear sometime next year after I have invested time and
>>> effort
>>> into developing with it.
>>>
>>> Please tell me you are not going to pull a 'Tapestry' on me and
>>> other users
>>> by making future versions so ridiculously incompatible I have to
>>> rewrite my
>>> project again?
>>>
>>> Honestly, I'm looking for a framework that will allow me to:
>>>
>>> 1) Utilize HTML templates (which you do, I understand).
>>> 2) Utilize CSS (which you do) files externally for my artist.
>>> 3) Utilize Javascript (which I assume you do).
>>> 4) Utilize a Java, component based web framework for creating a fast
>>> lightweight but rich user experience for my users (which I guess you
>>> do).
>>>
>>> I have just purchased Wicket in Action so as I can do some research,
>>> but I
>>> do appreciate your time if possible.
>>>
>>> Many thanks for your help, and your help.
>>>
>>> Regards, Graeme.
>>
>> ---------------------------------------------------------------------
>> 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--tp20254394p20254748.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
>
>

---------------------------------------------------------------------
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.

You are possibly correct. My main concern is that I have to upgrade from
Tapestry 4 to... something. Given that Tapestry 5 is not compatible in the
least I have allowed myself to look at the options.

I guess I am really asking for reasons to move from Tapestry to Wicket -
particularlu if anyone has any experience of doing this which they could
share. What were those reasons, and pros/cons after sampling both solutions.

Thanks for pointing out that I was not clear.


Daniel Frisk wrote:
> 
> I actually read your mail but I didn't quite get it, what is your main  
> concern?
> It seems to me like Wicket would be a perfect fit to your four criteria.
> 
> // Daniel
> jalbum.net
> 
> 
> On 2008-10-30, at 21:05, GK1971 wrote:
> 
>>
>> Hi. I hope this email is appropriate for the forum - its my first time
>> posting.
>>
>> My partner and I are in the process of working on a site that  
>> currently uses
>> Tapestry 4 and must be reasonably scalable vertically (we have  
>> horizontally
>> covered in a road map). I am looking around at technologies that we  
>> can
>> pursue in the future that will provide us with a way of creating a  
>> wonderful
>> experience for a user based on dynamic content with Java as a base  
>> language.
>>
>> I have used Tapestry 3 and 4 in prior lives in prior companies and as
>> Tapestry 5 was still early a year ago when we started the project I  
>> decided
>> to work with Tapestry 4 an understand that once the site was up and  
>> running
>> we may look at rewriting the web layer in an updated framework,  
>> using the
>> lessons we had learned along the way about our specific application.
>>
>> I have grown unhappy with Tapestry generally - for example, its clumsy
>> handling of AJAX. Even a seasoned developer can write a Tapestry  
>> application
>> which is incredibly complex and inefficient, also. I'm not certain its
>> declarative approach in Tapestry 5 is a wise thing from a  
>> productivity point
>> of view (maintenance). Debugging a Tapestry application can be  
>> difficult.
>>
>> I found myself looking at JSF, but we'd like to actually deliver a
>> functioning site quickly and not have our hands tied by bureaucracy.  
>> I also
>> looked into other frameworks, and short of writing something myself  
>> I have
>> found the best for our needs to be Tapestry 5 (scares me - what will
>> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>>
>> I'm liking the look of Wicket but I wondered if it would fill a few  
>> ideas I
>> have.
>>
>> I have had significant issues with DOJO/Tapestry bugs that I cannot  
>> fix
>> myself and that has limited productivity. I would like to write an  
>> AJAX
>> library for myself and hook it into Wicket somehow. Would this be  
>> possible.
>> I feel it may be a pain in Tapestry because there 'appears' to be  
>> such a
>> high coupling with DOJO now. Would it be conceptually easy for me to  
>> write
>> Javascript/AJAX and hook them into Wicket in a simple way? I  
>> understand
>> Wicket has a good framework for AJAX but if I require to implement  
>> code of
>> my own, is it easy to slip under the hood (with Tapestry this is  
>> very hard).
>>
>> Many forums have mentioned scalability is an issue, but I believe  
>> that this
>> is down to an applications individual handling of state rather than  
>> the
>> framework. Am I correct? I am not so worried about this vertical  
>> scaling as
>> long as I can horizontally scale my application on many servers  
>> (which I can
>> if I control state).
>>
>> What's the road map for Wicket? I understand it is now one of the main
>> Apache projects (which is one reason I am looking at it), so I  
>> assume it
>> won't disappear sometime next year after I have invested time and  
>> effort
>> into developing with it.
>>
>> Please tell me you are not going to pull a 'Tapestry' on me and  
>> other users
>> by making future versions so ridiculously incompatible I have to  
>> rewrite my
>> project again?
>>
>> Honestly, I'm looking for a framework that will allow me to:
>>
>> 1) Utilize HTML templates (which you do, I understand).
>> 2) Utilize CSS (which you do) files externally for my artist.
>> 3) Utilize Javascript (which I assume you do).
>> 4) Utilize a Java, component based web framework for creating a fast
>> lightweight but rich user experience for my users (which I guess you  
>> do).
>>
>> I have just purchased Wicket in Action so as I can do some research,  
>> but I
>> do appreciate your time if possible.
>>
>> Many thanks for your help, and your help.
>>
>> Regards, Graeme.
> 
> ---------------------------------------------------------------------
> 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--tp20254394p20254748.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?

[Daniel Frisk <da...@jalbum.net>]

I actually read your mail but I didn't quite get it, what is your main  
concern?
It seems to me like Wicket would be a perfect fit to your four criteria.

// Daniel
jalbum.net


On 2008-10-30, at 21:05, GK1971 wrote:

>
> Hi. I hope this email is appropriate for the forum - its my first time
> posting.
>
> My partner and I are in the process of working on a site that  
> currently uses
> Tapestry 4 and must be reasonably scalable vertically (we have  
> horizontally
> covered in a road map). I am looking around at technologies that we  
> can
> pursue in the future that will provide us with a way of creating a  
> wonderful
> experience for a user based on dynamic content with Java as a base  
> language.
>
> I have used Tapestry 3 and 4 in prior lives in prior companies and as
> Tapestry 5 was still early a year ago when we started the project I  
> decided
> to work with Tapestry 4 an understand that once the site was up and  
> running
> we may look at rewriting the web layer in an updated framework,  
> using the
> lessons we had learned along the way about our specific application.
>
> I have grown unhappy with Tapestry generally - for example, its clumsy
> handling of AJAX. Even a seasoned developer can write a Tapestry  
> application
> which is incredibly complex and inefficient, also. I'm not certain its
> declarative approach in Tapestry 5 is a wise thing from a  
> productivity point
> of view (maintenance). Debugging a Tapestry application can be  
> difficult.
>
> I found myself looking at JSF, but we'd like to actually deliver a
> functioning site quickly and not have our hands tied by bureaucracy.  
> I also
> looked into other frameworks, and short of writing something myself  
> I have
> found the best for our needs to be Tapestry 5 (scares me - what will
> Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
>
> I'm liking the look of Wicket but I wondered if it would fill a few  
> ideas I
> have.
>
> I have had significant issues with DOJO/Tapestry bugs that I cannot  
> fix
> myself and that has limited productivity. I would like to write an  
> AJAX
> library for myself and hook it into Wicket somehow. Would this be  
> possible.
> I feel it may be a pain in Tapestry because there 'appears' to be  
> such a
> high coupling with DOJO now. Would it be conceptually easy for me to  
> write
> Javascript/AJAX and hook them into Wicket in a simple way? I  
> understand
> Wicket has a good framework for AJAX but if I require to implement  
> code of
> my own, is it easy to slip under the hood (with Tapestry this is  
> very hard).
>
> Many forums have mentioned scalability is an issue, but I believe  
> that this
> is down to an applications individual handling of state rather than  
> the
> framework. Am I correct? I am not so worried about this vertical  
> scaling as
> long as I can horizontally scale my application on many servers  
> (which I can
> if I control state).
>
> What's the road map for Wicket? I understand it is now one of the main
> Apache projects (which is one reason I am looking at it), so I  
> assume it
> won't disappear sometime next year after I have invested time and  
> effort
> into developing with it.
>
> Please tell me you are not going to pull a 'Tapestry' on me and  
> other users
> by making future versions so ridiculously incompatible I have to  
> rewrite my
> project again?
>
> Honestly, I'm looking for a framework that will allow me to:
>
> 1) Utilize HTML templates (which you do, I understand).
> 2) Utilize CSS (which you do) files externally for my artist.
> 3) Utilize Javascript (which I assume you do).
> 4) Utilize a Java, component based web framework for creating a fast
> lightweight but rich user experience for my users (which I guess you  
> do).
>
> I have just purchased Wicket in Action so as I can do some research,  
> but I
> do appreciate your time if possible.
>
> Many thanks for your help, and your help.
>
> Regards, Graeme.

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