> Jonathan Locke wrote: > in fact, maybe the idea that the component is needed at all > is the hack... just musing...
Perhaps in this situation it might be. In the future I foresee a need to call modelChanging/Changed() though. > > i don't think so. i think the other idea is a hack. how can an > > interface to a component that's pagable not yield the > component that's > > to be paged? it makes perfect sense to me. Right, but putting getComponent() into the IPageableComponent will basically make it an adapter and outside the class hirarchy. Public Component getComponent() { return this; } would be pretty weird if a component implements IPageableComponent directly. -Igor > > > > Igor Vaynberg wrote: > > > >> 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Ì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_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