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]
