I can see your point. My thinking has always been that any abstract class has an implicit interface which is the sum of its public methods, and that there really is no difference between evolving public methods in an abstract class and evolving an interface and its single implementation. This is of course different when an interface is intended as a joint point between two systems or when alternate implementations are expected.
I am far more interested in finding a good solution for the IPageableComponent than discussing philosophies. The need for this arose when I was writing DataView. I wanted to reuse navigation components that worked with listview, such as PageableListViewNavigation, PageableListViewNavigationLink, etc. In their current state they were tightly coupled to listview, so I had to decouple them, thus the IPageableComponent interface. Inside it it has all the methods that those navigation components need to manipulate the listview, so now instead of getting the listview directly they get an instance of IPageableComponent and do the manipulation through that. Now all my dataview had to do is implement IPageableComponent and it could magically be navigated by the navigation components. Pretty clean and simple, however, the navigation components expect IPageableComponent to also be a component. For example, PageableListViewNavigationLink needs access to the page that the pageable component is on. Because of this I had to add a Page getPage() implemented by Component to the interface. This is the part that I am trying to find a cleaner solution for, and this is why I suggested Icomponent. If we had Icomponent IPageableComponent could extend that and also be used as a regular component. An alternate solution I can see is to get rid of IPageableComponent and use a PageableAdapter class with a getComponent() method inside. So instead of PageableListViewLink(...., dataview) it would be PageableListViewLink(...., new PageableAdapter(dataview)). This solution seems a bit unnatural to me because it goes around the inheritance hirarchy. What are your thoughts? Thanks, Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonathan Locke > Sent: Tuesday, August 02, 2005 3:41 PM > To: wicket-user@lists.sourceforge.net > Subject: Re: [Wicket-user] Sigin Example > > > Igor Vaynberg wrote: > > >Jonathan, > > > >Could you please elaborate on why interfaces are "fragile". > It doesn't > >click for me. How is it more fragile to have an interface > and a single > >implementation as opposed to a base class with no interface? > > > > > an interface is fragile because it is an inflexible, fixed > contract. it really is /set in stone/ for a large project > with a long lifespan (which we all hope wicket will be). > if you think about it, on a very widely used framework you > really can never ever change an interface. ever. i don't > know about you... but i'm not smart enough to get an > interface with more than a couple of methods right the first > time and for all time. i usually discover weeks or months > later (or days or hours... > DOH!) that i > forgot something. that's the fragility i'm talking about. > > i believe that one shouldn't generally define interfaces for > things that have contracts that are likely to evolve. > especially if they are likely to evolve significantly and/or > rapidly. if you have more than a few methods, the odds seem > to increase exponentially with each added method that you'll > eventually have that DOH! moment where you realize that you > didn't really fully understand the contract you long ago (or > not so long ago) thought was so clever... > > an abstract base class has all the abstractness of an > interface, but allows flexible default implementation that is > not fixed for all time. you can think of it very loosely as > a mixture between a class and an interface if you like. > non-abstract methods can at least be added even if the > existing abstract methods can't be changed without breaking > the world. interestingly, you can also theoretically > /remove/ the abstractness of abstract methods (loosening the > contract) without breaking subclasses by concretizing methods > later. in any case, for things that need the ability to > evolve in the way that Component has (take a look at the > revision history, we're on version > #164 of that file... and I don't think that includes 100+ > versions of that code from my original codebase), an > interface doesn't make sense unless there's some other > urgent, overriding need for it. > > in general, there can be other arguments that override the > disadvantage of interface inflexibility, such as a > requirement to allow alternate implementations not based on > the same root functionality, enabling mix-in usage or some > other usage driven need like making something Remote. none > of these seemed or seem like important factors in wicket. > > >As far as mixins go, I only ran into one situation so far. The > >IPageableComponent interface has to have getPage() method > which really > >has nothing to do with the implementation being pageable, > but with the > >fact that it is a component. Everything that uses IPageableComponent > >expects a component with pageable behaviour, not just a pageable > >something. Im not screaming interfaces for everything, but > in this case it would be nice. > > > > > i don't know enough about this case to comment. but i highly > suspect that there is some answer that doesn't involve making > Component or Page an interface. > > >Thanks, > >Igor > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf > Of Jonathan > >>Locke > >>Sent: Tuesday, August 02, 2005 2:29 PM > >>To: wicket-user@lists.sourceforge.net > >>Subject: Re: [Wicket-user] Sigin Example > >> > >> > >>i think you're awfully, awfully full of yourself (in fact, > you sound > >>like me about 10 years ago... ;-)). have you even considered the > >>possibility that it might be /you/ that doesn't get it? > >> > >>from my perspective: > >> > >> loose coupled interfaces == bell bottom jeans > >> > >>people think that they're the solution to everything right now. > >>and just like bell bottom jeans, some people really did > look good in > >>them. they were cool. but what were we thinking!? > >>does /everyone/ look good in bell bottom jeans? hardly. > >>just watch "that 70's show" sometime... the neighbor guy with the > >>curly hair. > >>he's an example of a guy that definitely doesn't need loose > coupling. > >> > >>when you've been doing this as long as i have, you start to notice > >>patterns in the fads that sweep through the industry. > >>and you eventually start to ignore the hype where it > doesn't make any > >>sense. > >>i could see this whole "bind-everything-with-xml" fad several years > >>ago coming from a mile away. and now what? people are > attracted to > >>wicket because it didn't follow that fad. i think you're simply > >>missing the forest for the trees. loose coupled interfaces are the > >>right design pattern for a whole host of problems. but the > design for > >>a web ui framework is not one of them. this was one of the things > >>that turned me off when i looked at tapestry. all these gigantic > >>interfaces? > >>why? yuck. > >> > >>don't get me wrong... please, keep thinking. we all have > to learn by > >>experience. i promise i won't stop you from trying to loose couple > >>every object in /your/ project with gigantic fragile > interfaces that > >>serve no practical purpose. but please don't try to do it > to wicket. > >>interfaces have been used judiciously in wicket. i'm not > saying it's > >>perfect. > >>i'm not even saying we shouldn't add an interface here or > there. we > >>just have yet to hear an even remotely reasonable argument > that wicket > >>components should be mixins. and that's why they aren't. > >> > >>David Liebeherr wrote: > >> > >> > >> > >>>Uh ohh, i started reading the dicussion about interfaces in wicket. > >>>I think Eleco and Jonathan might be wrong in some ways. > >>> > >>> > >>> > >>>>One /very/ important reason not to use interfaces in this > >>>> > >>>> > >>case is that: > >> > >> > >>>>interfaces are hard to evolve. Interfaces have to be pretty darn > >>>>stable before even considering throwing them out in the > >>>> > >>>> > >>public, as > >> > >> > >>>>there is no way (not without a tough fight at least) you > >>>> > >>>> > >>can alter > >> > >> > >>>>it later on - even adding a new method will break all clients. > >>>> > >>>> > >>>He sais that interfaces have to be more stable than an > >>> > >>> > >>object without > >> > >> > >>>interface. > >>>But he misses a very important fact: > >>>Assume you have "String str = new String()" String is a concrete > >>>class. but: String in this context is _ALSO_ an interface! > >>>Every reference is an interface no mather if it's a > >>> > >>> > >>concrete class or > >> > >> > >>>an interface/abstract class! > >>>And i think it should be not that hard to design proper interfaces! > >>> > >>> > >>> > >>>>jonathan: interfaces should always be a set of methods that you > >>>>cannot ever imagine extending > >>>> > >>>> > >>>"interface B extends A" ? interface inheritance is fun, > >>> > >>> > >>isn't it? :-) > >> > >> > >>>>[22:43] jonathan: my ideal number of methods in an interface is 1 > >>>>[22:43] jonathan: ;-) [22:44] jonathan: 2 is okay in some cases > >>>>[22:44] jonathan: 3 often should be re-thought > >>>> > >>>> > >>>i don't see what's the sens of defining a random number as > an limit > >>>for number of methos in an interface. > >>>an interface should be designed by the needs of the > context and the > >>>purposal. > >>>i just disagree with him! > >>> > >>> > >>> > >>>>I wonder what it is you want > >>>>to do with a proxy that you can"t do by simply > >>>> > >>>> > >>subclassing? Or AOP? > >> > >> > >>>He considers to use such a complex thing like AOP but > >>> > >>> > >>refuses to use > >> > >> > >>>such a basic thing like Interfaces? > >>> > >>>Did you and your colegues read the links i sent in my last mail? > >>>If not i suggest it would be a good idea to do so. > >>>It's worth it, trust me! > >>> > >>> > >>> > >>>>Johan Compagner wrote: > >>>>But this is not really possible because the internals of page are > >>>> > >>>> > >>>pretty > >>> > >>> > >>>>importand for wicket to let it work > >>>> > >>>> > >>>This is a serious indication that the design has some flaws > >>> > >>> > >>in it. A > >> > >> > >>>design should always be as interchangebale and modular as possible. > >>> > >>>Again: I think in the discussion it's missed that you can > >>> > >>> > >>even resuse > >> > >> > >>>an implementation in a interfaces based design by delegation... > >>>And it ignores the fact that you can extend interfaces as well > >>>(interface inheritance is a nice thing)... > >>>I can't imagine what's so hard to have a Page just as > Interface. If > >>>you can not deal with client objects as interfaced objects > >>> > >>> > >>you have a > >> > >> > >>>problem in your design. I do use interfaces every day and i > >>> > >>> > >>have never > >> > >> > >>>ever had a big problem with that. It's all about how familiar and > >>>comfortable you with good modular design pratics. Loosly > >>> > >>> > >>coupling is > >> > >> > >>>the key word! and loosly coupling is possible. you may have > >>> > >>> > >>to think a > >> > >> > >>>bit more about your design, but it safes you so much time later... > >>> > >>>Maybe if i have some time i will rewrite a very little part > >>> > >>> > >>of wicket > >> > >> > >>>to use interfaces to show that it's definetly not a problem to use > >>>interfaces and that you will get good benefits from it. > >>>Btw: A good design isn't done in a sec, but it's worth to > thake the > >>>time to do so... > >>> > >>>Another thing i don't understand is, that some ppl > >>> > >>> > >>sometimes say that > >> > >> > >>>the refuse to use interfaces on wicket but sometimes there are > >>>interfaces used in wicket. So if you can use an interface for a > >>>sessionFactory then why can't you use an interface for the session > >>>itself? > >>> > >>>Well, however, i think when wicket reaches 2.0 and it's > >>> > >>> > >>clear enough > >> > >> > >>>which functionalities are implemented i may be a good idea > >>> > >>> > >>to review > >> > >> > >>>the source and move over to use interfaces where they make sense... > >>> > >>> > >>>And one thing not to forget: Wicket uses "wicket:id" tags > to loosly > >>>couple html with the logic-code. That is the most valuable > >>> > >>> > >>thing about > >> > >> > >>>wicket! > >>>But it's a bad thing to not continue the loosly coupling > aproach in > >>>the api. Think about it! Loosly compling on the html/code > >>> > >>> > >>side is the > >> > >> > >>>key thing that makes wicket better than other frameworks. > >>> > >>> > >>So continue > >> > >> > >>>to use that in the api and you have done the best way that > >>> > >>> > >>is possible > >> > >> > >>>with java! > >>> > >>> > >>>And please remeber: It's cunstructive critism which i try > >>> > >>> > >>to provide. > >> > >> > >>>I just want to get wicket as the best what's possible bc the basic > >>>ideas of wicket are great! > >>> > >>>Thanx for your attention, > >>>Dave > >>> > >>>PS: I don't say i know the overall truth i just provided my toughts > >>>:-) > >>> > >>>Juergen Donnerstag wrote: > >>> > >>> > >>> > >>>>David, > >>>> > >>>>we did have a very hot discussion about that topic just a > >>>> > >>>> > >>week or two > >> > >> > >>>>ago. Please check the mail archiv (gmane) for details. But > >>>> > >>>> > >>I can tell > >> > >> > >>>>you it was a very deliberate decison to implement it the > way it is. > >>>> > >>>>Juergen > >>>> > >>>>On 8/2/05, David Liebeherr <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Juergen, > >>>>> > >>>>>Juergen Donnerstag wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>David, > >>>>>> > >>>>>>yes you're right we have to work on the docs, has been > >>>>>> > >>>>>> > >>on our list > >> > >> > >>>>>>and is under construction. Did you check out our wiki and (the > >>>>>>outdated) user guide. it should provide at a beginner > >>>>>> > >>>>>> > >>some inside into Wicket. > >> > >> > >>>>>>You mentioned you would simplifiy the API even further. You > >>>>>>mentioned IModel. Anything else that comes into your mind? > >>>>>> > >>>>>> > >>>>>> > >>>>>I my gosh, do you realy want to get me started on that? > >>>>> > >>>>> > >>:-) No, for > >> > >> > >>>>>real: > >>>>>There are lot's of things that need very much simplification. > >>>>>When i have some time, we may discuss that in detail (if you are > >>>>>interested) in a chat or something like that (Log of > chat goes to > >>>>>maillinglist/wiki of course). > >>>>> > >>>>>One of the much important things is to realize the > >>>>> > >>>>> > >>"programm to an > >> > >> > >>>>>interface, not to an implementation" principle. > >>>>>For exmaple: > >>>>>Session should be an Interface and SessionImpl should be (one!) > >>>>>implementation of it. > >>>>>Btw: Don't name interfaces with a I prefix, that is not so good. > >>>>>It should be always like that: > >>>>>Car exmaple: > >>>>>interface Car {}; > >>>>>class CarImpl impements Car {}; > >>>>>or > >>>>>class BmwImpl implements Car{}; > >>>>> > >>>>>I know ppl have different opinions about such things, but the i > >>>>>discussed those things for a rather long time with a lot of > >>>>>developers and some very very good (actually one of the best > >>>>>programmers out there). I have lot's of serious reasons > >>>>> > >>>>> > >>why i think > >> > >> > >>>>>you should follow this naming convention. And the most important > >>>>>thing is: Use interfaces rather then concrete implementation! > >>>>>And another very very thing is: Use delegation rather > >>>>> > >>>>> > >>than concrete > >> > >> > >>>>>inheritance! > >>>>> > >>>>>Again, i have very serious reasons why i think that way. > >>>>>And it does not mean much more work to do with proper > >>>>> > >>>>> > >>coding tools > >> > >> > >>>>>(Like IntelliJ IDEA). > >>>>> > >>>>>I think the Idea of Wicket is geniusly! > >>>>>Especialy the part that code is attached to free > >>>>> > >>>>> > >>placeable tags with > >> > >> > >>>>>a proper wicket:id! > >>>>> > >>>>>But i think at this point the API needs a revision to > simplify it > >>>>>and to realy follow some very important rules (like avoiding > >>>>>concrete inheritance). > >>>>>Btw: have a look on that: > >>>>>http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-too lbox.html > >>>>>AND AFTER THAT ALSO READ THAT! --> > >>>>>http://jtiger.org/articles/why-extends-is-not-evil.html > >>>>> > >>>>>It explains very very well what's the problem with concrete > >>>>>inheritance. > >>>>> > >>>>>And last but not least: > >>>>>I think you core developers have done a very good job and > >>>>> > >>>>> > >>i'm very > >> > >> > >>>>>happy to use wicket! > >>>>>Everything i said (and will say) is not meant as a > >>>>> > >>>>> > >>complain i realy > >> > >> > >>>>>want to participate in wicket and to make it the best WebApp > >>>>>framework that exists (And i think wicket can reach that > >>>>> > >>>>> > >>target! If > >> > >> > >>>>>i think about all that XMl-Config files crap like with > Struts and > >>>>>JSF :-)) > >>>>> > >>>>>So please always thake what i say at what is it meant to be: > >>>>>Constructive critism. > >>>>> > >>>>>Thanx again for your Work, > >>>>>Dave > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Juergen > >>>>>> > >>>>>>On 8/2/05, David Liebeherr <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Juergen Donnerstag wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Sorry, I guess except the javadoc there is no extra > doc on it. > >>>>>>>>What is > >>>>>>>>your question? Signin and Signin2 and not very complex. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>I think this is precisely the Problem. > >>>>>>>I found it already out by myself, but it took me some > >>>>>>> > >>>>>>> > >>time to find > >> > >> > >>>>>>>and understand that the key thing is the checkAccess-method. > >>>>>>>You think it is very simple code. But you are one of the > >>>>>>>Developers that wrote the Libs, so you know what > checkAccess do > >>>>>>>and you know that you do not have to search in the > >>>>>>>WebApplication-Class code to search where it is > >>>>>>> > >>>>>>> > >>redirected to the > >> > >> > >>>>>>>Login-Page. > >>>>>>>So i think the problem is for outsiders and newbees of > >>>>>>> > >>>>>>> > >>the project > >> > >> > >>>>>>>many many things are not so clear as you might think. > >>>>>>> > >>>>>>>I think the lack of good Documentation - and by > documentation i > >>>>>>>don't mean a simple doc of the API methods, rather a > >>>>>>> > >>>>>>> > >>documentation > >> > >> > >>>>>>>describes the realtionships between components and how > >>>>>>> > >>>>>>> > >>to use them > >> > >> > >>>>>>>- is one of the biggest problems (or todos) for wicket. > >>>>>>> > >>>>>>>Another Problem is, that's at least my personal opinion (and > >>>>>>>please thake it as constructive critic and not just as > >>>>>>> > >>>>>>> > >>a complain) > >> > >> > >>>>>>>is that the api is yet to complex. I thought one of the > >>>>>>> > >>>>>>> > >>main goals > >> > >> > >>>>>>>of wicket was to keep the learning curve as low as > >>>>>>> > >>>>>>> > >>possible. But > >> > >> > >>>>>>>the api is to complex for that i think. Especialy the > >>>>>>> > >>>>>>> > >>IModel API > >> > >> > >>>>>>>is very complex and i think it would be a very good idea to > >>>>>>>simplify it much more. > >>>>>>> > >>>>>>>I mean at this time i am a newbee to wicket for my > >>>>>>> > >>>>>>> > >>self. But that > >> > >> > >>>>>>>is good bc that way i can provide the "sight of a newbee". > >>>>>>>Developers of the proect may thing that something is > >>>>>>> > >>>>>>> > >>"quite easy", > >> > >> > >>>>>>>but if i'm a developer of the project i know too much > >>>>>>> > >>>>>>> > >>already to > >> > >> > >>>>>>>tell if a thing can be easy understood. > >>>>>>> > >>>>>>>But however thanks for your help, Dave > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Juergen > >>>>>>>> > >>>>>>>>On 8/1/05, David Liebeherr <[EMAIL PROTECTED]> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Is there any documentation/tutorial available for the Signin > >>>>>>>>>Exmaple? > >>>>>>>>>I realy have some problems understanding how it works. > >>>>>>>>> > >>>>>>>>>Thanx, > >>>>>>>>>Dave > >>>>>>>>> > >>>>>>>>>PS: Wicket ROCKS! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>------------------------------------------------------- > >>>>>>>>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>>>>>>>>Strategies > >>>>>>>>> > >>>>>>>>>from IBM. Find simple to follow Roadmaps, straightforward > >>>>>>>>>articles, > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>informative Webcasts and more! Get everything you > >>>>>>>>> > >>>>>>>>> > >>need to get up > >> > >> > >>>>>>>>>to speed, fast. > >>>>>>>>>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>>>>>>>_______________________________________________ > >>>>>>>>>Wicket-user mailing list > >>>>>>>>>Wicket-user@lists.sourceforge.net > >>>>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>------------------------------------------------------- > >>>>>>>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>>>>>>>Strategies > >>>>>>>> > >>>>>>>>from IBM. Find simple to follow Roadmaps, straightforward > >>>>>>>>articles, > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>informative Webcasts and more! Get everything you need > >>>>>>>> > >>>>>>>> > >>to get up > >> > >> > >>>>>>>>to speed, fast. > >>>>>>>>http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >>>>>>>>_______________________________________________ > >>>>>>>>Wicket-user mailing list > >>>>>>>>Wicket-user@lists.sourceforge.net > >>>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>------------------------------------------------------- > >>>>>>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>>>>>>Strategies > >>>>>>> > >>>>>>>from IBM. Find simple to follow Roadmaps, straightforward > >>>>>>>articles, > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>informative Webcasts and more! Get everything you need > >>>>>>> > >>>>>>> > >>to get up > >> > >> > >>>>>>>to speed, fast. > >>>>>>>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>>>>>_______________________________________________ > >>>>>>>Wicket-user mailing list > >>>>>>>Wicket-user@lists.sourceforge.net > >>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>------------------------------------------------------- > >>>>>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>>>>>Strategies from IBM. Find simple to follow Roadmaps, > >>>>>>straightforward articles, informative Webcasts and more! Get > >>>>>>everything you need to get up to speed, fast. > >>>>>>http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >>>>>>_______________________________________________ > >>>>>>Wicket-user mailing list > >>>>>>Wicket-user@lists.sourceforge.net > >>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>> > >>>>>> > >>>>>> > >>>>>------------------------------------------------------- > >>>>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>>>>Strategies from IBM. Find simple to follow Roadmaps, > >>>>> > >>>>> > >>straightforward > >> > >> > >>>>>articles, informative Webcasts and more! Get everything > >>>>> > >>>>> > >>you need to > >> > >> > >>>>>get up to speed, fast. > >>>>>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>>>_______________________________________________ > >>>>>Wicket-user mailing list > >>>>>Wicket-user@lists.sourceforge.net > >>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>> > >>>>> > >>>>> > >>>>> > >>>------------------------------------------------------- > >>>SF.Net email is sponsored by: Discover Easy Linux Migration > >>> > >>> > >>Strategies > >> > >> > >>>from IBM. Find simple to follow Roadmaps, straightforward > articles, > >>>informative Webcasts and more! Get everything you need to > get up to > >>>speed, fast. > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>_______________________________________________ > >>>Wicket-user mailing list > >>>Wicket-user@lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>> > >>> > >>> > >>------------------------------------------------------- > >>SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > >>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>informative Webcasts and more! Get everything you need to get up to > >>speed, fast. > >>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>_______________________________________________ > >>Wicket-user mailing list > >>Wicket-user@lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > >> > >> > >> > >> > > > > > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > >from IBM. Find simple to follow Roadmaps, straightforward articles, > >informative Webcasts and more! Get everything you need to get up to > >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opÌk > >_______________________________________________ > >Wicket-user mailing list > >Wicket-user@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies from IBM. Find simple to follow Roadmaps, > straightforward articles, informative Webcasts and more! Get > everything you need to get up to speed, fast. > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
