I am pro explicit contracts, but for dataproviders I think the general
use would be stateless, so no detach behavior necessary.
If we let IDataProvider extend IDetachable, then we have a lot of code
breaks. Though these can easily be resolved by extending the following
class instead of directly
You mean that developers can have such a thing?
because in the core we dont have a AbstractDataProvider.
Also we have some code breaks but in wicket 2.0 IDataProvider already
extended IDetachable a long time now
So we are then in sync with 2.0 on that api level. That is a pro for me.
johan
On
I mean that we can add the AbstractDataProvider as a means for those
that just implemented the interface ad-hoc.
In our application have on several occaisions the following:
IDataProvider provider = new IDataProvider() { ... };
This code will break with the change. Having AbstractDataProvider
i dont really see the point. i think most usecases are using
sortabledataprovider, at least i think 99% for the code i wrote.
-igor
On 12/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
ahh ok we could introduce that.
I don't know what is easier.. in eclipse:
cursor on the new IDataProvider
On 12/8/06, Johan Compagner [EMAIL PROTECTED] wrote:
shouldn't we extend from IDetachable in 1.3?
i dont see a problem with that
-igor
johan
On 12/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess if you are certain the size never changes this works ok
-igor
On 12/7/06,
the question is is this really necessary because we have already code that
does the detach:
Note that if the IDataProvider implementation implements [EMAIL PROTECTED]
IDetachable}
* interface, the [EMAIL PROTECTED] IDetachable#detach()} method will be called
at the
end
* of request.
So if
well the thing here is expressiveness. the way it is right now was done to
avoid api breaks.
but if you look at the idataprovider - how do you know that you can make the
impl also implement idetachable and that will work? same can be said for
models, why have IModel extend IDetachable? it is so
Well, I just do two queries the first time... retrieving total count
on size() call (just once), and then retrieve iteration on
iterator(...) call (every navigation event)... so, in steady-state is
only one call...
On 12/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well in the example i gave you
i guess if you are certain the size never changes this works ok
-igor
On 12/7/06, Manuel Barzi [EMAIL PROTECTED] wrote:
Well, I just do two queries the first time... retrieving total count
on size() call (just once), and then retrieve iteration on
iterator(...) call (every navigation
My question is, nevertheless, would it be a significant implementation
change to swap calls order from to current to iterator(...) first and
size() later? then adding support for both cases in a
SortableDataProvider (Case 1: Big databases - 2 Calls, Case 2: Small
databases - 1 Call)...
From my
no its not possible there is logic that ties the return call of size() to a
few things that need to happen before the call to iterator()
all it takes is your own subclass that i have shown you, i dont think its a
big deal.
-igor
On 12/5/06, Manuel Barzi [EMAIL PROTECTED] wrote:
My
Yes, I have already followed your sample, doing two queries to database... ;)
On 12/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
no its not possible there is logic that ties the return call of size() to a
few things that need to happen before the call to iterator()
all it takes is your own
well in the example i gave you there should only be one query to the
database
-igor
On 12/5/06, Manuel Barzi [EMAIL PROTECTED] wrote:
Yes, I have already followed your sample, doing two queries to
database... ;)
On 12/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
no its not possible there
the only assumption made is that it is cheaper to retrieve a (total
count+window) rather then (the entire dataset), which holds true almost
always. some exceptions being an in-memory database.
Or if the window size is sort of the total count, which i guess is also
quite common..
Not all list
.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manuel
Barzi
Sent: Thursday, November 23, 2006 6:25 AM
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] SortableDataProvider, size() iterator(int
first,int count), Correct execution order?
Hi, there,
I
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag
von Frank Silbermann
Gesendet: Freitag, 24. November 2006 15:25
An: wicket-user@lists.sourceforge.net
Betreff: Re: [Wicket-user] SortableDataProvider, size()
iterator(int first,int count), Correct execution order?
About DataTable
2006 15:25
An: wicket-user@lists.sourceforge.net
Betreff: Re: [Wicket-user] SortableDataProvider, size()
iterator(int first,int count), Correct execution order?
About DataTable and SortableDataProvider, I believe the
designer's assumptions are that in typical use:
(1) the DataProvider
Hi, there,
I have the following composition:
WebPage ...
... DataView CustomProvider extends SortableDataProvider
... PagingNavigator DataView
The ERROR? I found is this:
When clicking on any of the navigation buttons (PagingNavigator), my
CustomProvider implementation is managed by Wicket
Hi, there,
I have the following composition:
WebPage ...
... DataView CustomProvider extends SortableDataProvider
... PagingNavigator DataView
The ERROR? I found is this:
When clicking on any of the navigation buttons (PagingNavigator), my
CustomProvider implementation is managed by Wicket
size() is meant to retrieve the total number of entries
iterator() is meant to retrieve the subset that fits into the current page
so these two things are largely unrelated - eg two different queries to the
database
still there is enough flexibility to accomplish what you want
class
20 matches
Mail list logo
