Just thought of adding getComponent() to IPageableComponent, still a hack in my opinion.
-Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Igor Vaynberg > Sent: Tuesday, August 02, 2005 5:04 PM > To: wicket-user@lists.sourceforge.net > Subject: RE: [Wicket-user] Sigin Example > > 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=ick > _______________________________________________ > 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
