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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>>>>
>>>> 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: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20264444.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to