and
didn't test.
Looking forward to some feedback.
-Igor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Johan Compagner
Sent: Sunday, July 31, 2005 6:25 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
please post
-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
Okay, I see what you're saying. I think it would be cool to
have it work like this: run through the Iterator from the
DataSource and, using pks, determine if the current list
exactly matches the one from the last request. If so, do
nothing. Oth
Oh sorry, I meant the code that you attached to this topic about 20 or so up.
On 7/30/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> Which rfe?
>
> -Igor
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find
Which rfe?
-Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Saturday, July 30, 2005 10:50 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> I just found the c
I just found the code you attached to the rfe. I really like that. The
amount of complexity it removes it ridiculous. I'll definitely give it
a try as soon as it's committed.
On 7/30/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> I am writing the code. I will commit it hopefully tomorrow.
>
> -Ig
I am writing the code. I will commit it hopefully tomorrow.
-Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Saturday, July 30, 2005 10:11 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re
Okay, I see what you're saying. I think it would be cool to have it
work like this: run through the Iterator from the DataSource and,
using pks, determine if the current list exactly matches the one from
the last request. If so, do nothing. Otherwise, re-render the whole
thing. This way the list is
> > I was thinking of having iterator(int first, int count, DataView
> > dataView) which would eliminate the requirement for keeping
> state in
> > the dataprovider and still let you work directly off the interface.
>
> Are you looking to have these DataProviders be singletons?
> That could ma
ilto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Friday, July 29, 2005 9:59 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
i'm wondering if we shouldn't leave the existing listview
stuff alone altogether and instead start a new db-centric
CollectionVie
I like it. Anything that gets some database-centric stuff into the
wicket core is fine by me. It's good to have specific DB helper stuff
(Hibernate, JDBC, EJB, etc) in the side projects, but it would be nice
to have the stuff that applies to all datastores in the main distro.
On 7/29/05, Jonathan
> I was thinking of having iterator(int first, int count, DataView dataView)
> which would eliminate the requirement for keeping state in the dataprovider
> and still let you work directly off the interface.
Are you looking to have these DataProviders be singletons? That could
make your getModel(O
TECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jonathan Locke
> Sent: Friday, July 29, 2005 9:59 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
>
> i'm wondering if we shouldn't leave the existing listview
> stuff alone al
> No, the query cache only caches the primary keys...
This sounds exactly like iterate() but you have to remember to call
setCachable(true).
> One thing I would add though, would be a setPageableListView() method.
> If the DataProvider knows about its container, it can do
> cleanup things when i
i'm wondering if we shouldn't leave the existing listview stuff alone
altogether and instead start
a new db-centric CollectionView that can handle all this new stuff. one
thing i keep running
into with hibernate is that i want to view Sets instead of lists. a
DatabaseCollectionView
could be
No, the query cache only caches the primary keys. The first time it's
run all the objects are sent accross and each one is cached by primary
key. The set of primary keys returned for that query are also cached.
Then, the next time the same query is run, it issues a select for each
key in the cached
> Yea, I can see how that would work. You're just saying to put
> the "black box" in the ListView, right?
There is no black box. The paging that the pagedlist does is no longer
necessary.
> Your DataProvider
> interface is a bit too simple (doesn't allow ordering, and
> EJB and Hibernate2 can't
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Phil Kulak
> > Sent: Friday, July 29, 2005 5:03 PM
> > To: wicket-user@lists.sourceforge.net
> > Subject: Re: [Wicket-user] lists
> >
&
9, 2005 5:03 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> On 7/29/05, Christian Essl <[EMAIL PROTECTED]> wrote:
> > Igor needs an eight-liner where you need a helper-class which is
> > complicated enough to put in an extra contri
On 7/29/05, Christian Essl <[EMAIL PROTECTED]> wrote:
> Igor needs an eight-liner where you need a helper-class which is
> complicated enough to put in an extra contribution-package.
> OrderedPageList adds some indirection to get something which is less
> efficient and more work to use.
My "eight-
On Fri, 29 Jul 2005 14:27:39 -0700, Phil Kulak <[EMAIL PROTECTED]> wrote:
On 7/29/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
Once again, this has become a philosophical discussion.
I say tomato you say tomato.
This is going to live as a contrib package so it wont distrub anything,
people who
> Does DataProvider implement java.util.List? Because unless it
> does, I don't have a List. ;)
omg
I meant you can transparently use your list with a dataview
Igor
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategie
On 7/29/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> Once again, this has become a philosophical discussion.
> I say tomato you say tomato.
>
> This is going to live as a contrib package so it wont distrub anything,
> people who prefer this style will use it.
>
> Besides you can do
>
> final
have to reconstruct a list from an iterator
}
}
-Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Friday, July 29, 2005 1:55 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket
> > It's just as easy to build paging into a List as it is
> > into the component itself.
> > However, the way it is currently, my DAO can return a paging
> > list and set up exactly how said List gets it's data each
> > time it pages; exactly what a DAO is supposed to do.
>
> Unfortunately the on
t; To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> I am not even sure the following interface will be used at
> all, but maybe I can contribute in a small way with my small
> comment on the names.
>
> > interface IteratorProvider{
> >int
I am not even sure the following interface will be used at all, but
maybe I can contribute in a small way with my small comment on the names.
interface IteratorProvider{
int size();
Iterator iterator(int start, int minCount);
}
This very similar to the Java 5 Iterable interface.
What ab
View work fine for me.
-Igor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Essl
Sent: Friday, July 29, 2005 9:41 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
>> interface IteratorProvider{
>> int
uly 29, 2005 9:41 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> >> interface IteratorProvider{
> >> int size();
> >> Iterator iterator(int start, int minCount);
> >
> > IModel model(Object o); <== d
interface IteratorProvider{
int size();
Iterator iterator(int start, int minCount);
IModel model(Object o); <== do you like that?
}
Shall we rename dataview to iteratorview?
I was thinking about the name again. (Good names are very important for
new users and for C
As far as I'm concerned they can go. I've never used them myself, and
see no very common usecase in them. If you want them remove, pls open up
a bug report and/ or start a vote on the dev list.
Eelco
I was thinking about the moveUp and moveDown links. I do not
need them
often and if I need t
> On the other hand your approach is definately more consistent
> and clear.
> Especially if a plain List (Collection) is provided it hast
> to be wrapped
> anyway. After all I do not know. It remainds me of SWT versus
> SWING. Give
> the final power more to the component or the model?
I am
On Thu, 28 Jul 2005 07:51:36 -0700, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
I would say in you DataView:
protected ListItem newItem(final int index, final Object object) {
return new ListItem(index,
getDataProvider().getObjectModel(object));
}
protected IModel getListItemModel(Object ob
> I actually meant that the iterator must at least return the
> minCount of values - it does not matter if it returns more or
> not. So it could load only the elements up to minCount or in
> case it is backed by a list it could return
> list.listIterator(index). The DataView just does not care
> I'm not sure if this is still a debate. but I really like
> keeping ListView and PageableListView's model plain old
> lists.
We are not changing the framework, we are working on additional components.
I like the dataprovider interface because it is much more low level then the
general list in
Hi Igor,
If I understand you correctly you would like to provide the min amount of
entries and have the iterator access more if they are needed? If so,
this is
one of the things I was trying to eliminate. Currently dataview asks your
dataprovider for the exact segment of data it needs and so i
I'm not sure if this is still a debate. but I really like keeping
ListView and PageableListView's model plain old lists. It's just as
easy to build paging into a List as it is into the component itself.
However, the way it is currently, my DAO can return a paging list and
set up exactly how said Li
> Why not have
>
> public interface DataProvider extends Serializable {
>
> Iterator getElements(int first, int minCount);
> int getCount();
> }
>
I was definetely thinking of doing that, didn't get to it yet. A list was
simply the most convinient because that's what EntityManager r
work
with navigation classes that currently only support listviews.
Igor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Essl
Sent: Wednesday, July 27, 2005 1:06 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
Hi,
I am
urceforge.net
> Subject: Re: [Wicket-user] lists
>
> Could you attach those to the rfe please?
>
> Thanks,
>
> Eelco
>
> Igor Vaynberg wrote:
>
> >Hi Christian,
> >Attached are my proof-of-concept classes ive been playing
> around with.
> >Basica
these work
with navigation classes that currently only support listviews.
Igor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Essl
Sent: Wednesday, July 27, 2005 1:06 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Christian Essl
> Sent: Wednesday, July 27, 2005 1:06 PM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> Hi,
>
> I am quite a new Wicket
Hi,
I am quite a new Wicket user and have to agree with Igor. I found ListView
always a bit 'magical' confusing. I do not realy understand wheter I've to
keep my list (indexed) stable between calls and in case of DB backed lists
how to do that. If I want to provide a custom model which methods
Having 2 versions, one for < 1.5 and one for >= 1.5, is I guess out
of the question as well? (like commons-collections)
It would be great to at least javadoc stuff as if it were developed
for 1.5.
Erik.
> As a framework we can't do that yet i am afraid.
> i think even 1.2 will be to soon.
As a framework we can't do that yet i am afraid.
i think even 1.2 will be to soon. As wicket is a server tech and that is
the one place that doesn't upgrade easy.
I personally also would like to generfy everything. But maybe if even
J2EE that is released early next year (with EJB3)
everybody
ts.sourceforge.net
> Subject: Re: [Wicket-user] lists
>
> I would love to see IModel defined as IModel, personally.
> But I don't know how that would shake out for < 1.5 people.
>
> On 7/25/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > with 1.5 we could do
I would love to see IModel defined as IModel, personally. But I
don't know how that would shake out for < 1.5 people.
On 7/25/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> with 1.5 we could do compile time checking in the constructor of listview:
>
> something like:
> public ListView(final Str
with 1.5 we could do compile time checking in the constructor of listview:
something like:
public ListView(final String id, final IModel model)
Then that type safety is there. We only need then a maybe replacement
for List.
johan
Igor Vaynberg wrote:
Once again, I don't understand the flexib
> >Once again, I don't understand the flexibility issue. We were not
> >talking about replacing the imodel interface, but the list
> interface,
> >both approaches can be wrapped in an imodel. What
> flexibility do you lose?
> >
> >
>
> Actually, I was. Having such a nested specific interface
Igor Vaynberg wrote:
Discussing on improvements is allways good. I think we could
improve in the field of type safety, and model clarity.
However, as far as I can see, this is hard/ impossible to do
without either losing flexibility (e.g. being able to use
property models directly) or ending
> Discussing on improvements is allways good. I think we could
> improve in the field of type safety, and model clarity.
> However, as far as I can see, this is hard/ impossible to do
> without either losing flexibility (e.g. being able to use
> property models directly) or ending up with a lot
You are right I can do that no problem.
What I was trying to achieve in all these discussions is to create a
simpler/standard/non-list-dependent/more user-aware way to do this because I
thought other people would have the same problem and thus would need a
similar solution. However, since no one
> > As opposed to IModel getListItemModel(final IModel listViewModel,
> > final int
> > index) ?
> > What exactly does index mean in a context of a database
> backed list?
> > What kind of a model does listViewModel represent?
> >
>
> Ok didn't know you would use that method to get a listite
As opposed to IModel getListItemModel(final IModel listViewModel, final int
index) ?
What exactly does index mean in a context of a database backed list? What
kind of a model does listViewModel represent?
Ok didn't know you would use that method to get a listitem model.
But this you alread
listview or pageablelistview are both not limited to anything.
They can do both just fine.
Igor Vaynberg wrote:
I think that ListView should stay how it is, and PageableListView
should have a method like IModel getObjectModel(Object o). Maybe even
make it abstract. I use ListView all over the pl
Igor Vaynberg wrote:
Once again, we shouldn't limit our discussion to hibernate. Is wicket
gearing to only support hibernate? What if I am using jdbc?
Nope, we want to support nothing in partcular/ everything possible.
Eelco
---
SF.Net e
Once again, we shouldn't limit our discussion to hibernate. Is wicket
gearing to only support hibernate? What if I am using jdbc?
As far as hibernate goes, the answer to your question is yes and no. You can
mark objects as lazy and that will put them behind a proxy which will load
the data at firs
> I think that ListView should stay how it is, and PageableListView
> should have a method like IModel getObjectModel(Object o). Maybe even
> make it abstract. I use ListView all over the place for displaying a
> list of items that may or may not have come from a database. However,
> PageableListVi
>> 2) in order to use primary keys we need to translate an object into a
>> pk-based model. Currently this is done by overriding a method in a
listview,
>> however, this is a horizontal concern and should be separated.
> I don't want those methods in the model. That is a -1 from me.
> I like the c
I think that ListView should stay how it is, and PageableListView
should have a method like IModel getObjectModel(Object o). Maybe even
make it abstract. I use ListView all over the place for displaying a
list of items that may or may not have come from a database. However,
PageableListView really
2) in order to use primary keys we need to translate an object into a
pk-based model. Currently this is done by overriding a method in a listview,
however, this is a horizontal concern and should be separated.
I don't want those methods in the model. That is a -1 from me.
I like the current
> database driven webapps may use primary key, but wicket needs to be
> general enough to display lists that are simply any ordered collection.
> the current code works, so we need to consider all aspects of lists
> and listviews to make changes. we really shouldn't restrict a general
> class li
As far as I know hibernate cannot page transparently, if it could there
would be no need for the pagedlist class with black magic inside. Also,
hibernate should not be the only persistence interface considered, there are
plenty more in use right now that are not as advanced.
I have a couple of con
62 matches
Mail list logo
