> 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
