What are your thoughts on changing void setCurrentPage(int page) to int setCurrentPage(int page) in Ipageable and having it return the bounded page?
-Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johan Compagner > Sent: Monday, September 05, 2005 8:16 AM > To: wicket-user@lists.sourceforge.net > Subject: Re: [Wicket-user] PageableGridDataView > > just remove those 2 for DataView > I don't think anybody will use them for DataView > > Igor Vaynberg wrote: > > Gili, > > > > All you would be doing is factoring out semantic incompatibilities > > into the strategy interface/impls. In a way the old > pageabledataview > > was a navigation strategy for the regular dataview. Please try to > > understand the problem. Let me lay it out for you: > > > > The dataview class has setFirstIndex() and setViewSize() methods. > > The pagabledataview extends the dataview and so inherits those, > > alongside introducing the setCurrentPage()/setRowsPerPage(). > > > > The problem is that setFirstIndex() and setViewSize() do not make > > sense in the pageable subclass. What does setViewSize(5) > mean when you > > already called setRowsPerPage(10)??? What does > setFirstIndex(10) mean > > when you called setCurrentPage(5)? > > > > That's the problem. It has nothing to do with design > patterns and java > > 101 lessons. > > > > Currently when paging is enabled setFirstIndex() and setViewSize() > > will throw an illegalstateexception which makes perfect > sense to me, > > you shouldn't call those if you enabled paging. Also > setCurrentPage() > > will throw the same exception when called while paging is disabled. > > > > What we are discussing is simply removing setFirstIndex() and > > setViewSize() because with paging built in they are not > that useful. > > You lose some flexibility, but not too much. > > > > Maybe now that all the research is laid out for you you > can post some > > meaningful comments. > > > > -Igor > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Gili > >> Sent: Sunday, September 04, 2005 11:27 AM > >> To: wicket-user@lists.sourceforge.net > >> Subject: Re: [Wicket-user] PageableGridDataView > >> > >> > >> It sounds to me like you might be able to use the > Strategy design > >> pattern here. Your design (mentioned in a previous email) > made a lot > >> more sense to me than Igor's idea of throwing "unsupported" > >> exceptions. > >> In essense, you could say there are two available navigation > >> strategies so far: linear and page-oriented. Then you simply allow > >> users to plug them in and everything should (hopefully) be > clean from > >> inheritance point of view. > >> > >> Gili > >> > >> Christian Essl wrote: > >> > >>> On Fri, 02 Sep 2005 18:04:31 -0400, Gili > >>> > >> <[EMAIL PROTECTED]> wrote: > >> > >>>> What is the reason? The new method sounds very > anti-OOP to me. > >>>> Usually one layers functionality using interfaces. > >>>> > >> Stuffing them all > >> > >>>> into the base class but having them throw exceptions when > >>>> > >> "disabled" > >> > >>>> sounds a lot like a flat object model to me. > >>>> > >>> The reason for unifying them in one base class is also to > make the > >>> inheritance hierarchy smaller, less deep and more > >>> > >> consistent. If you > >> > >>> split DataView and PageableDataView than you also have to make a > >>> GridDataView and a PageableGridDataView. Two classes which > >>> > >> are from the > >> > >>> hierarchy total unreleated but are otherwise more or less > the same. > >>> > >>> Further if you look at the old code of DataView and > >>> > >> PagabeableDataView > >> > >>> the PageableDataView is not easy to understand, because > you have to > >>> consider two classes with all the protected and overriding > >>> > >> co-work. A > >> > >>> general problem with inheritance, which gets worse the deeper the > >>> hierarchy is. > >>> > >>> And last but most important the user has to learn two > classes where > >>> there always remains some uncertainty wheter the > >>> > >> child-class does indeed > >> > >>> behave like the super class, because it could always > override some > >>> methods (as it currently does). > >>> > >>> So I am realy for merging them in one class. > >>> > >>> Christian > >>> > >>> > >>>> Gili > >>>> > >>>> Johan Compagner wrote: > >>>> > >>>> > >>>>> that is something we had.. and want to get rid of i think.. > >>>>> > >>>>> johan > >>>>> > >>>>> > >>>>> Gili wrote: > >>>>> > >>>>> > >>>>>> Igor Vaynberg wrote: > >>>>>> > >>>>>> > >>>>>>> Yes the support delegate is lazily created. > >>>>>>> > >> Setcurrentpage() throws > >> > >>>>>>> illegalstateexception if paging is disabled. > >>>>>>> > >>>>>> > >>>>>> Sounds like an anti-pattern to me. Why don't you > have a base > >>>>>> class without Pagable support and a subclass that is Pagable > >>>>>> (always) with these methods. > >>>>>> > >>>>>> Gili > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------- > >>>>>> SF.Net email is Sponsored by the Better Software > >>>>>> > >> Conference & EXPO > >> > >>>>>> September 19-22, 2005 * San Francisco, CA * Development > >>>>>> > >> Lifecycle > >> > >>>>>> Practices > >>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * > >>>>>> Testing & QA Security * Process Improvement & Measurement * > >>>>>> http://www.sqe.com/bsce5sf > >>>>>> _______________________________________________ > >>>>>> Wicket-user mailing list > >>>>>> Wicket-user@lists.sourceforge.net > >>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>> > >>>>>> > >>>>> ------------------------------------------------------- > >>>>> SF.Net email is Sponsored by the Better Software > Conference & EXPO > >>>>> September 19-22, 2005 * San Francisco, CA * Development > Lifecycle > >>>>> Practices Agile & Plan-Driven Development * Managing Projects & > >>>>> > >> Teams * Testing > >> > >>>>> & QA > >>>>> Security * Process Improvement & Measurement * > >>>>> http://www.sqe.com/bsce5sf > >>>>> _______________________________________________ > >>>>> Wicket-user mailing list > >>>>> Wicket-user@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>> > >>>>> > >>> > >>> > >> -- > >> http://www.desktopbeautifier.com/ > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices Agile & Plan-Driven Development * Managing > Projects & Teams > >> * Testing & QA Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Wicket-user mailing list > >> Wicket-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > >> > >> > >> > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices Agile & Plan-Driven Development * Managing > Projects & Teams > > * Testing & QA Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & > EXPO September 19-22, 2005 * San Francisco, CA * Development > Lifecycle Practices Agile & Plan-Driven Development * > Managing Projects & Teams * Testing & QA Security * Process > Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
