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