what do you mean with bounded page?
most of the time it will just return the page that is the input?
and sometimes just the last page? (if the input was to large?)
johan
Igor Vaynberg wrote:
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
-------------------------------------------------------
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
