On Fri, Oct 31, 2008 at 11:17 AM, GK1971 <[EMAIL PROTECTED]> 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 <[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] > >
