Re: Moving from Tapestry to Wicket?
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
at 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Moving from Tapestry to Wicket?
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
>> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
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
Re: Moving from Tapestry to Wicket?
t;> - >>>>> 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 &g
Re: Moving from Tapestry to Wicket?
ng 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--tp20254394p2026.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]
Re: Moving from Tapestry to Wicket?
e >>>>> 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--tp20254394p2026.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]
Re: Moving from Tapestry to Wicket?
>>> 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] >>> >>> >>> >>> >> >> > > -- > -Wicket for love > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > > > - > 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]
Re: Moving from Tapestry to Wicket?
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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
gt;> 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--tp20254394p2026.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]
Re: Moving from Tapestry to Wicket?
equire 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]
Re: Moving from Tapestry to Wicket?
On Thu, Oct 30, 2008 at 4:24 PM, GK1971 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/msg03279.html As you can see, it fell on deaf (and sometimes condescending) ears. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Tapestry to Wicket?
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
Re: Moving from Tapestry to Wicket?
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 >
Re: Moving from Tapestry to Wicket?
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]
Moving from Tapestry to Wicket?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
