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
ahh ok we could introduce that.
I don't know what is easier.. in eclipse:
cursor on the new IDataProvider -> CTRL-1 and done.
johan
On 12/9/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I mean that we can add the AbstractDataProvider as a means for those
that just implemented the interface
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
ar
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 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 im
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 t
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 som
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 1
IDataProvider should just have detach/attach methods
But i see this will happen:
* TODO 2.0: directly extend [EMAIL PROTECTED] IDetachable}
*
*/
public interface IDataProvider extends Serializable
So that you have a detach and an attach that are called before and after the
size/iterator
So that
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 event)
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 y
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 th
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
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 questi
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 po
On 11/25/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> 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
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 i
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 and SortableDataProvider, I believe the
> designer's
t; Von: [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
methods to use.
-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 or
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 CustomDataPr
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 Wick
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 Wick
23 matches
Mail list logo