Re: [Wicket-user] Why I recommended Wicket...
nice :) why this thread is our biggest Achilles heal is beyond me.. http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709 johan On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
What do you mean ? Paolo On 12/21/06, Johan Compagner [EMAIL PROTECTED] wrote: why this thread is our biggest Achilles heal is beyond me.. http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709 johan On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
I really like the guy who say : which one is the better, emacs or VI. This is the exact same point here and I like the irony of making this statement in that post! Even if I never touch to tapestry, I think it should be good enough. Why in open source (In general, it's not my first mailling list) there is always a battle of me bing more powerfull than you. Is nobody can accept that things are great and complementory. Anyway, was just a little tired this morning to see those kind of thread, but since I continue to post on them, I'm surely not better than anyone else! :) Marc On 12/20/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Здравствуйте, Marc-Andre. Вы писали 21 декабря 2006 г., 19:05:39: I really like the guy who say : which one is the better, emacs or VI. This is the exact same point here and I like the irony of making this statement in that post! Even if I never touch to tapestry, I think it should be good enough. Why in open source (In general, it's not my first mailling list) there is always a battle of me bing more powerfull than you. Is nobody can accept that things are great and complementory. It is not only open source or closed thing! Because we are human beings, we have set up our preferences. It is in our nature, we like something and dislike other things. We have favorites everywhere, in sports, in programming languages, in frameworks, and so on. So get over it, at the end everyone wins. BTW, I'm leaning towards making wicket my favorite! So, be prepared for a war. You are warned! ;) Anyway, was just a little tired this morning to see those kind of thread, but since I continue to post on them, I'm surely not better than anyone else! :) Marc On 12/20/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- С уважением, shumbola mailto:[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
I think I seriously owe an apology here. I seriously didnt mean to start a flame war. Its just that I c'dnt help posting this - as this was the first time I ran into a wicket related post in the Tapestry user list. and the 'achilles heel' came along later. ( may be i should have seen it coming) I think I have addressed the *apparent* Achilles heel though in a 'nice' manner as Eelco usually advocates :) . peace. thanks, Karthik On 12/21/06, Johan Compagner [EMAIL PROTECTED] wrote: nice :) why this thread is our biggest Achilles heal is beyond me.. http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709 johan On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
you didn't start a flame ware here I just commented on a bit that they think that thread has something to do that is bad with wicket (our Achilles heel) why that is is strange. What was wrong with that thread except that we didn't support and removed something that we didn't want to improve and flamewars when a bit civilized are always nice to have.. Keep the humor a bit alive! johan On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote: I think I seriously owe an apology here. I seriously didnt mean to start a flame war. Its just that I c'dnt help posting this - as this was the first time I ran into a wicket related post in the Tapestry user list. and the 'achilles heel' came along later. ( may be i should have seen it coming) I think I have addressed the *apparent* Achilles heel though in a 'nice' manner as Eelco usually advocates :) . peace. thanks, Karthik On 12/21/06, Johan Compagner [EMAIL PROTECTED] wrote: nice :) why this thread is our biggest Achilles heal is beyond me.. http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709 johan On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote: someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
someone else picked it up too ;-) http://www.nabble.com/Can-you-comment-on-this--tf2858705.html regards Karthik On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote: And InfoQ picked up this thread: http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Indeed. One might say that Wicket is better than most other frameworks for the same reason that C++ is better than C, that Java is better than Pascal, or that Smalltalk is better than Basic. Wicket allows you to use inheritance to help re-use webpages. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Sonnek Sent: Thursday, December 14, 2006 5:02 PM To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] Why I recommended Wicket... Other points of consideration is long term maintenance. A component oriented framework like Wicket encapsulates component functionality into a black box that can be used in many different contexts and still work as designed. The same effect is very difficult to achieve with custom tags (especially when they have external dependencies like javascript, etc). Well said. I think this is one of the best accomplishments of wicket. IMO, re-usable JSP tags are nearly impossible, while reusable wicket components are extremely quick and easy to use. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Wicket is the framework that I've been looking for for a long time. The certain feature of wicket that made itself the fovorite of mine is it doesn't allow me (and anyone from my co-programmers) to put programming logic in the markup. A little wicket-specific tags, one wicket:id attribute and that's it. Page authors in my team is very happy because they don't have to learn and memorize gazillions of web framework tags anymore. All they have to concern about is html/css/javascript and their beloved Dreamweaver. And aside from this, they can preview the page that they are designing. And they don't have to be bothered anymore by programmers very often. IMO, this is the true separation of concerns between programmers and visual designers. Programmers have concern only about java code. They don't have to intervene frequently with the designer's markup (majority of programmers can't do visually appealing pages, in the first place). Likewise, designers have concern only about the html pages. They don't have to, or they hate to, see programming logic in the html markup. On 15/12/06, Ryan [EMAIL PROTECTED] wrote: A few months ago I wrote to the Wicket user list explaining that I was investigating view frameworks for a large enterprise project. This is a follow up to that post explaining why I recommended Wicket. It may be useful for other people who are going through the same decision process. First a bit about my background. I have been building java web applications for about 6 years. During this time I worked with custom jsp view frameworks, struts, spring mvc, and tapestry. I spent the last two years working very closely with Tapestry 3 (and a small amount with Tapestry 4) on several high throughput/high availability web applications for a large dot com. Assume for the rest of this email I am evaluating web frameworks for large projects that will be maintained and enhanced for the foreseeable future (choosing a view framework for a quick, small, one-off application is a very different discussion). --- I have read a considerable amount about the different view frameworks out there the past few months. While each have their merits I decided to focus on JSF (myfaces), Spring MVC, and Wicket for the purpose of doing a deeper examination and small prototype application. That does not mean that Seam, Rife, Trails, Tapestry, etc are not worth looking at but in my opinion the three I choose were the best of breed for their type. I quickly determined that myfaces was not for me. I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it. Spring in general is a great project and I can not speak highly enough about the products they produce. One very important contrast between Spring MVC and other frameworks (especially Wicket) is that Spring MVC is bare bones. It really is just a MVC framework. If you want infrastructure for ajax, redirect after post, poups, and other common webisms you will need to build them yourself with Spring MVC. This can be a good thing if you have unique requirements that should be custom built in the first place but for most projects this is not the case. Other points of consideration is long term maintenance. A component oriented framework like Wicket encapsulates component functionality into a black box that can be used in many different contexts and still work as designed. The same effect is very difficult to achieve with custom tags (especially when they have external dependencies like javascript, etc). The Benefits of Wicket: 1. All configuration is done in java. In my opinion this is a huge plus. This helps development as well as long term maintenance because there is one place to look for view logic. Frameworks like Tapestry or JSP that allow you to place configuration in any number of places which makes it difficult to track down the source of a bug. Using java also allows you to use refactoring tools which can be a big boost in productivity during development and makes it easier to verify what your changes may effect. 2. Well thought out support for common webisms (ajax, redirect after post, etc). Instead of spending development time figuring out how you are going to wire dwr or your own ajax framework Wicket provides a great foundation for building ajax enabled components. The redirect after post problem is something that every web application has to solve at one point or another and Wicket provides 3 very good solutions out of the box. 3. Strong community with active core members. The project looks very healthy and has a bright future ahead. 4. Powerful model abstraction. At first the Model abstraction doesn't look very impressive but in practice it is a very powerful design pattern that works well with the rest of the framework. Negatives of Wicket: 1. Session support. Many other web frameworks do not use sessions out of the box. Wicket uses the session
Re: [Wicket-user] Why I recommended Wicket...
Despite the trade off you depict very well, I can still the benefits of this approach: - no more session time outs, - infinite number of pages in pagemaps, - and a bit more theoretic: smooth scalability. I say theoretic since it is not likely you'll need this kind of scaling. Regards, Erik. Igor Vaynberg wrote: client side storage doesnt really make sense. what you make up in ram you give up in cpu+bandwidth. which is cheaper? lets say you have a page that is 30k big when the object graph is serialized. you need to store it on the client. you need to encode it first, usually base64 encoding which results in 33% increase in size - since this is the most commonly used method lets go with it ( you can also use something like yenc which will result in smaller size but higher cpu utilization ). so now your 30k page is 40k encoded. user requests this page, this html is rendered+40k hidden field. user submits a form/clicks a link, now you submit the data for the form/link + 40k hidden field. then your cpu needs to decode it, deserialize it - so now instead of using session you are 80k per request overhead in bandwidth + cpu power to decode it. we know the cpu power scales - just throw more nodes into the cluster - but it doesnt really scale per request because that is a single thread. so in every request you have the overhead of transferring 40k + decoding + deserialization + serialization + encoding. is it worth it? ram is cheap, if you are serious about clustering your project you can prob afford a box with 4gb ram - thats even little for servers nowadays. lets say out of that only 2gb is avail to the servlet container, how many 30k pages can you fit into 2gb? -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
On 12/17/06, Erik van Oosten [EMAIL PROTECTED] wrote: Despite the trade off you depict very well, I can still the benefits of this approach: - no more session time outs, That depends, then we also have to serialize the WebSession with every page. The problem with that approach e is that you also rollback your websession when using the back button So when you are now on page X and you go to Page Y and then Z by that you do set something in the session Then the user presses twice on the back button and you are back to page X and you submit. If then you also restore the session object you have lost the values what you have done when you where in Y and Z In our attempt to make it work see wicket 2.0 the ClientPageSavingSessionStore class. We only serialize the page itself. But not the session. - infinite number of pages in pagemaps, Thats already being solved by the SecondLevelCacheSessionStore - and a bit more theoretic: smooth scalability. I say theoretic since it is not likely you'll need this kind of scaling. And that is just what igor was trying to explain. You will not get smooth scalability Because much more cpu power is needed and more importantly external bandwidth. johan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
- and a bit more theoretic: smooth scalability. I say theoretic since it is not likely you'll need this kind of scaling. And that is just what igor was trying to explain. You will not get smooth scalability Because much more cpu power is needed and more importantly external bandwidth. Actually that makes the curve on the graph with the required number of boxes against the number of users even more smooth! For this curve it does not matter that you need more CPU and more bandwidth. The point is that the curve will resemble a line even when you need to support millions of users. - no more session time outs, That depends, then we also have to serialize the WebSession with every page. The problem with that approach e is that you also rollback your websession when using the back button So when you are now on page X and you go to Page Y and then Z by that you do set something in the session Then the user presses twice on the back button and you are back to page X and you submit. If then you also restore the session object you have lost the values what you have done when you where in Y and Z I see. Yes that would be a very hard problem. - infinite number of pages in pagemaps, Thats already being solved by the SecondLevelCacheSessionStore Good to have a more solid solution then client serialization. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
client side storage doesnt really make sense. what you make up in ram you give up in cpu+bandwidth. which is cheaper? lets say you have a page that is 30k big when the object graph is serialized. you need to store it on the client. you need to encode it first, usually base64 encoding which results in 33% increase in size - since this is the most commonly used method lets go with it ( you can also use something like yenc which will result in smaller size but higher cpu utilization ). so now your 30k page is 40k encoded. user requests this page, this html is rendered+40k hidden field. user submits a form/clicks a link, now you submit the data for the form/link + 40k hidden field. then your cpu needs to decode it, deserialize it - so now instead of using session you are 80k per request overhead in bandwidth + cpu power to decode it. we know the cpu power scales - just throw more nodes into the cluster - but it doesnt really scale per request because that is a single thread. so in every request you have the overhead of transferring 40k + decoding + deserialization + serialization + encoding. is it worth it? ram is cheap, if you are serious about clustering your project you can prob afford a box with 4gb ram - thats even little for servers nowadays. lets say out of that only 2gb is avail to the servlet container, how many 30k pages can you fit into 2gb? -igor On 12/15/06, Carfield Yim [EMAIL PROTECTED] wrote: 1. Session support. Many other web frameworks do not use sessions out of How about this approach of store session data? Or part of session data? http://weblogs.java.net/blog/gmurray71/archive/2005/05/storing_secure.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
umm... a whole bunch? like about 65K pages. igor.vaynberg wrote: client side storage doesnt really make sense. what you make up in ram you give up in cpu+bandwidth. which is cheaper? lets say you have a page that is 30k big when the object graph is serialized. you need to store it on the client. you need to encode it first, usually base64 encoding which results in 33% increase in size - since this is the most commonly used method lets go with it ( you can also use something like yenc which will result in smaller size but higher cpu utilization ). so now your 30k page is 40k encoded. user requests this page, this html is rendered+40k hidden field. user submits a form/clicks a link, now you submit the data for the form/link + 40k hidden field. then your cpu needs to decode it, deserialize it - so now instead of using session you are 80k per request overhead in bandwidth + cpu power to decode it. we know the cpu power scales - just throw more nodes into the cluster - but it doesnt really scale per request because that is a single thread. so in every request you have the overhead of transferring 40k + decoding + deserialization + serialization + encoding. is it worth it? ram is cheap, if you are serious about clustering your project you can prob afford a box with 4gb ram - thats even little for servers nowadays. lets say out of that only 2gb is avail to the servlet container, how many 30k pages can you fit into 2gb? -igor On 12/15/06, Carfield Yim [EMAIL PROTECTED] wrote: 1. Session support. Many other web frameworks do not use sessions out of How about this approach of store session data? Or part of session data? http://weblogs.java.net/blog/gmurray71/archive/2005/05/storing_secure.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/Why-I-recommended-Wicket...-tf2822928.html#a7908915 Sent from the Wicket - User mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
You can do what every you want.
in Wicket1.3/2.0 you don't have only the choice of what we have now
(SecondLevelCache or the 1.2.x way of doing things)
No you can be in control what to do with the pages that are falling out of
the pagemap.
The pagemap only hold 1 page anymore, so session are very light weight.
But the second level cache has this constructor:
public SecondLevelCacheSessionStore(final IPageStore pageStore)
This is the default IPageStore we use:
WebApplication.newSessionStore()
{
return new SecondLevelCacheSessionStore(new FilePageStore());
}
And that FilePageStore is the one that saves all pages to the
javax.servlet.context.tempdir per sessionid.
And deletes all of them when a session gets unbound.
So if you only want X pages stored to disk. Implement your own IPageStore
or extend FilePageStore and re implement the storePage(String sessionId,
Page page) method.
If you want real replication then make a DatabasePageStore that is storing
pages to a shared database
I am thinking about adding this one to core that can be configured by giving
it a JDNI context or something like that.
When you have this then pages are being able to get from any app server
(even after one dies)
i would always use a sticky session clustering solution with a buddy system
for app server clustering
But if one fails then in the current situations if you don't share the disk
then yes the back button doesn't work
So if you have a web app and one server dies. and a session goes to the
other one. If at that time so the next request
the user does use the back button then there will be an expired page
exception. But if he doesn't use the back button
and just goes on he won't notice anything.
So in my eyes this is a solution that covers it all pretty much. It is not
100% when the back button is used on a crash
but for the rest everything works. So how much do you want exactly? More?
Implement your own IPageStore
or use a shared disk.
johan
On 12/15/06, Francis Amanfo [EMAIL PROTECTED] wrote:
On 12/15/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
I
this is of course only the default behavior and the whole thing is still
easily configurable.
Ok, thats clear but want to know to what extent this would be
configurable. By that do you mean we can only configure two situations, one
that we choose to go with the new default behavior and the other being the
current situation where everything is stored in session?
It'll be nice and useful if we could also say only after N pages of
history should Wicket serialize to disk or database.
What about that?
Regards,
Francis
-igor
On 12/14/06, Nathan Hamblen [EMAIL PROTECTED] wrote:
Ryan wrote:
[...]
1. Session support. Many other web frameworks do not use sessions
out of
the box. Wicket uses the session extensively to store the render
state
of most renders. This leads to a large session and if you are not
careful a VERY large session. I understand Wicket 1.3 will address
this
however for the time being this is an important issue to be aware of
when evaluating Wicket ( for instance the simple act of using Link
to
create a link that executes java code when clicked causes the entire
page and children to be stored in the session).
I don't think that will be any different in 1.3, for a standard Link.
You want the magic, you gotta pay for it. The good thing is that
landing
pages and major entry points (that are bounce-heavy anyway) can soon
be
done in Wicket without opening unused sessions. You can make as many
pages/links bookmarkable and stateless as you need to. So using
Wicket
site-wide will be a lot easier argument to make, and we'll never have
to
write JSPs again! Yay!
(An entirely stateless Wicket app would be, in my mind, throwing out
the
baby...)
Nathan
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Beware of bugs in the above code;
I have only proved it correct, not tried it.
Re: [Wicket-user] Why I recommended Wicket...
Thanks Johan, this explanation is crystal clear! Very interesting stuff
indeed.
Regards,
Francis
On 12/16/06, Johan Compagner [EMAIL PROTECTED] wrote:
You can do what every you want.
in Wicket1.3/2.0 you don't have only the choice of what we have now
(SecondLevelCache or the 1.2.x way of doing things)
No you can be in control what to do with the pages that are falling out of
the pagemap.
The pagemap only hold 1 page anymore, so session are very light weight.
But the second level cache has this constructor:
public SecondLevelCacheSessionStore(final IPageStore pageStore)
This is the default IPageStore we use:
WebApplication.newSessionStore()
{
return new SecondLevelCacheSessionStore(new FilePageStore());
}
And that FilePageStore is the one that saves all pages to the
javax.servlet.context.tempdir per sessionid.
And deletes all of them when a session gets unbound.
So if you only want X pages stored to disk. Implement your own IPageStore
or extend FilePageStore and re implement the storePage(String sessionId,
Page page) method.
If you want real replication then make a DatabasePageStore that is storing
pages to a shared database
I am thinking about adding this one to core that can be configured by
giving it a JDNI context or something like that.
When you have this then pages are being able to get from any app server
(even after one dies)
i would always use a sticky session clustering solution with a buddy
system for app server clustering
But if one fails then in the current situations if you don't share the
disk then yes the back button doesn't work
So if you have a web app and one server dies. and a session goes to the
other one. If at that time so the next request
the user does use the back button then there will be an expired page
exception. But if he doesn't use the back button
and just goes on he won't notice anything.
So in my eyes this is a solution that covers it all pretty much. It is not
100% when the back button is used on a crash
but for the rest everything works. So how much do you want exactly? More?
Implement your own IPageStore
or use a shared disk.
johan
On 12/15/06, Francis Amanfo [EMAIL PROTECTED] wrote:
On 12/15/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
I
this is of course only the default behavior and the whole thing is
still easily configurable.
Ok, thats clear but want to know to what extent this would be
configurable. By that do you mean we can only configure two situations, one
that we choose to go with the new default behavior and the other being the
current situation where everything is stored in session?
It'll be nice and useful if we could also say only after N pages of
history should Wicket serialize to disk or database.
What about that?
Regards,
Francis
-igor
On 12/14/06, Nathan Hamblen [EMAIL PROTECTED] wrote:
Ryan wrote:
[...]
1. Session support. Many other web frameworks do not use sessions
out of
the box. Wicket uses the session extensively to store the render
state
of most renders. This leads to a large session and if you are not
careful a VERY large session. I understand Wicket 1.3 will address
this
however for the time being this is an important issue to be aware
of
when evaluating Wicket ( for instance the simple act of using Link
to
create a link that executes java code when clicked causes the
entire
page and children to be stored in the session).
I don't think that will be any different in 1.3, for a standard
Link.
You want the magic, you gotta pay for it. The good thing is that
landing
pages and major entry points (that are bounce-heavy anyway) can soon
be
done in Wicket without opening unused sessions. You can make as many
pages/links bookmarkable and stateless as you need to. So using
Wicket
site-wide will be a lot easier argument to make, and we'll never
have to
write JSPs again! Yay!
(An entirely stateless Wicket app would be, in my mind, throwing out
the
baby...)
Nathan
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
Re: [Wicket-user] Why I recommended Wicket...
Igor Vaynberg wrote: disadvantages being that fail over is harder unless the disk is shared between the cluster nodes. the disk can always be replaced by a database as well. the whole idea is relatively new and we have yet to explore its full potential. Yes... that is kind of gutsy. I don't know how many people are actually using replicated sessions across a cluster (my work uses cookie-stuck sessions), but it's important to have that option. (The shared resource cache is already a big hole in that support, right?) Seems like the best thing would be for the servlet container to swap Serializable session objects to disk on its own. Then we'd get the same benefit while using the session normally. Do any servlet containers do that? Nathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
You want the session to be as lightweight as possible in order for it to be easily replicated in a fault tolerant system. With service/dao layer code I like to let the ORM (EJB/Hibernate) cache whatever I need for performance. By keeping a cache of these objects in the application layer and a reference for how to retrieve them in the session (via an object's id) I get the best of both worlds. So lets say I have a Member object that I use heavily and want to cache it on the web/application server for performance reasons. In the user's session I set the memberId. Now when the user requests something that needs the Member object, I ask Hibernate to load the Member object and it will do so from cache if it didn't expire. If you have a cluster of servers and sticky sessions configured, the cached items on a particular server will be tailored to those people on the server because the sessions are sticky and they'll always be hitting the same server. Now, if one of the servers go down, you can have your router or whatever does the routing to the cluster redirect all requests for that session to another server. If you were replicating the session to that other server the user will fail over to that server and not notice an interuption in the service. When a request comes to the new server to load(Member, memberId) it won't have that Member cached, but it will retrieve it from the database and cache it again. It would be nice if Wicket could do something similar to this. I know you can't do the same thing because in the example I shown the Model is just an id pointing to a database record so it can be easily de/serialized from anywhere, while a Model in Wicket is more complicated. On 12/15/06, Nathan Hamblen [EMAIL PROTECTED] wrote: Igor Vaynberg wrote: disadvantages being that fail over is harder unless the disk is shared between the cluster nodes. the disk can always be replaced by a database as well. the whole idea is relatively new and we have yet to explore its full potential. Yes... that is kind of gutsy. I don't know how many people are actually using replicated sessions across a cluster (my work uses cookie-stuck sessions), but it's important to have that option. (The shared resource cache is already a big hole in that support, right?) Seems like the best thing would be for the servlet container to swap Serializable session objects to disk on its own. Then we'd get the same benefit while using the session normally. Do any servlet containers do that? Nathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Have you tried using LoadableDetachable models for that? Another way could be to use Terracotta for the clustering where the objects are just replicated to servers which need them. I haven't tried it yet but this approach seems pretty scalable and fault-tolerant to me (given that the Terracotta-server is redundant ;-)) roland On 12/15/06, Joe Toth [EMAIL PROTECTED] wrote: It would be nice if Wicket could do something similar to this. I know you can't do the same thing because in the example I shown the Model is just an id pointing to a database record so it can be easily de/serialized from anywhere, while a Model in Wicket is more complicated. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
1. Session support. Many other web frameworks do not use sessions out of How about this approach of store session data? Or part of session data? http://weblogs.java.net/blog/gmurray71/archive/2005/05/storing_secure.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Ryan wrote: [...] 1. Session support. Many other web frameworks do not use sessions out of the box. Wicket uses the session extensively to store the render state of most renders. This leads to a large session and if you are not careful a VERY large session. I understand Wicket 1.3 will address this however for the time being this is an important issue to be aware of when evaluating Wicket ( for instance the simple act of using Link to create a link that executes java code when clicked causes the entire page and children to be stored in the session). I don't think that will be any different in 1.3, for a standard Link. You want the magic, you gotta pay for it. The good thing is that landing pages and major entry points (that are bounce-heavy anyway) can soon be done in Wicket without opening unused sessions. You can make as many pages/links bookmarkable and stateless as you need to. So using Wicket site-wide will be a lot easier argument to make, and we'll never have to write JSPs again! Yay! (An entirely stateless Wicket app would be, in my mind, throwing out the baby...) Nathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
Other points of consideration is long term maintenance. A component oriented framework like Wicket encapsulates component functionality into a black box that can be used in many different contexts and still work as designed. The same effect is very difficult to achieve with custom tags (especially when they have external dependencies like javascript, etc). Well said. I think this is one of the best accomplishments of wicket. IMO, re-usable JSP tags are nearly impossible, while reusable wicket components are extremely quick and easy to use. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Why I recommended Wicket...
It is actually quiet a bit different. all visited pages except the most recent are saved to disk instead of being held in session. the session now only holds the most recently accessed page. the pages saved on disk are only needed when the user uses the back button, which is probably not that often. the advantages are that only the current page is held in session - so the session size is significantly reduced. since disk is pretty much unlimited you have as much back button support as you want. disadvantages being that fail over is harder unless the disk is shared between the cluster nodes. the disk can always be replaced by a database as well. the whole idea is relatively new and we have yet to explore its full potential. this is of course only the default behavior and the whole thing is still easily configurable. -igor On 12/14/06, Nathan Hamblen [EMAIL PROTECTED] wrote: Ryan wrote: [...] 1. Session support. Many other web frameworks do not use sessions out of the box. Wicket uses the session extensively to store the render state of most renders. This leads to a large session and if you are not careful a VERY large session. I understand Wicket 1.3 will address this however for the time being this is an important issue to be aware of when evaluating Wicket ( for instance the simple act of using Link to create a link that executes java code when clicked causes the entire page and children to be stored in the session). I don't think that will be any different in 1.3, for a standard Link. You want the magic, you gotta pay for it. The good thing is that landing pages and major entry points (that are bounce-heavy anyway) can soon be done in Wicket without opening unused sessions. You can make as many pages/links bookmarkable and stateless as you need to. So using Wicket site-wide will be a lot easier argument to make, and we'll never have to write JSPs again! Yay! (An entirely stateless Wicket app would be, in my mind, throwing out the baby...) Nathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
