Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-11 Thread Christian Essl
On Wed, 10 Aug 2005 19:37:32 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



Yes there is a synergy but the current methods are still
quite different - have to think abaout it. In case we make no
model mapping (a removeall for no iprimarykeyprovider) than
the counter is not realy needed.


Indeed, simply removeall() and use a local counter for the ids. We can 
still

wrap it in a iprimarykeyprovider.


Yes. Generally: I think if DataView is thought for relational DBs only 
than the primaryKey() should be kept in the interface, otherwise it should 
be not and equals should be used. Ggenerating primaryKeys without a 
backing DB for general Java Objects is not always easy and not the java 
way - equals is. The option of iprimarykeyprovider should remain in any 
case. Your decision.






Another thing:
Maybe in onRender instead of rendering over the viewSize we
could use the Component.size().


If we do this we would have to lock the add()/remove()/etc methods in the
dataview.

Or what we can do is record the number of actual dataitems added in
onbeginrequest in a field, and use that in render(). Thoughts?



Why do we have to lock them?

Just of my head:  A simple thing would be if we make a super class of 
DataView (call it TableView) where the user has to add/remove DataItems on 
his own - no model no onBeginRequest(). The user could add the DataItems 
from the outside - something like JGoodies PanelBuilder - or by overriding 
onBeginRequest. TableView would only onRender() repeat over them. 
TableView would have no model at all - perfect decoupling;-).
 






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-11 Thread Christian Essl
On Thu, 11 Aug 2005 08:20:06 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Essl



Equals() wont work because that wont be able to handle two of the same
object in the iterator.
Good point. You mean in your case of primaryKey an Exception is always 
thrown, because of the component-id check in the container and in my case 
not. Good catch this is a bug - thanks. The bug could either be solved by 
also throwing an Exception or by doing what I think the user rather 
expects, namely showing all Objects in the iterator (wheter double 
contained or not) and than making sure that on the next turn the DataItems 
which share an equal IModel are always removed and potentially recreated. 
I acutally think the second solution can be implemented with very little 
performance loss.



I think the solution would be pretty simple: if you
want optimized item removal you need to provide the primarykey - maybe we
can add some stuff to primarykey() params to make it easier.

I am not so keen on optimized item removal. I was more against a mandatory 
primaryKey() mehtod. Than I got tracked into showing that it is not 
needed.


I know you are short on time so thanks for the rather long discussion,
Christian





___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-11 Thread Igor Vaynberg
Just checked in a bunch of changes. Check them out and lets discuss.

Here is the gist:
Added RepeatingView which simply renders all its children in no particular
order - DataView no longer contains onRender()
Added OrderedRepeatingView extends RepeatingView this renders its children
in the order they were added.
DataView now extends OrderedRepeatingView and onBeginRequest has been
reworked to work with or without a IUniqueKeyProvider.

-Igor
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Thursday, August 11, 2005 12:56 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 On Thu, 11 Aug 2005 08:20:06 -0700, Igor Vaynberg 
 [EMAIL PROTECTED]
 wrote:
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  Christian Essl
 
  Equals() wont work because that wont be able to handle two 
 of the same 
  object in the iterator.
 Good point. You mean in your case of primaryKey an Exception 
 is always thrown, because of the component-id check in the 
 container and in my case not. Good catch this is a bug - 
 thanks. The bug could either be solved by also throwing an 
 Exception or by doing what I think the user rather expects, 
 namely showing all Objects in the iterator (wheter double 
 contained or not) and than making sure that on the next turn 
 the DataItems which share an equal IModel are always removed 
 and potentially recreated. 
 I acutally think the second solution can be implemented with 
 very little performance loss.
 
  I think the solution would be pretty simple: if you want optimized 
  item removal you need to provide the primarykey - maybe we can add 
  some stuff to primarykey() params to make it easier.
 
 I am not so keen on optimized item removal. I was more 
 against a mandatory
 primaryKey() mehtod. Than I got tracked into showing that it 
 is not needed.
 
 I know you are short on time so thanks for the rather long 
 discussion, Christian
 
   
 
   
   
 ___
 Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - 
 Hier anmelden: http://mail.yahoo.de
 
 
 
 ---
 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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-11 Thread Igor Vaynberg
The only thing that I don't really like is that I have to override
add/remove/removeall to get the ordering working - I think there should be a
template listener method that you can override like onChildAdded and
onChildRemoved.

For example currently autoAdd() calls add() internally so I don't override
it because that would add the component to the order twice - but is this a
clearly defined contract?

Also remove() doesn't get called when removeall() is called so I have to
override that also.

Do the two afore mentioned listeners make sense? Should I submit a patch?
That way I can just override onchildadded and onchildremoved w/out
overriding add/remove/removeall and the contract would be more clear.

-Igor


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Phil Kulak
 Sent: Thursday, August 11, 2005 3:41 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 Good job, Igor. I like the changes a lot.
 
 On 8/11/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
  Just checked in a bunch of changes. Check them out and lets discuss.
  
  Here is the gist:
  Added RepeatingView which simply renders all its children in no 
  particular order - DataView no longer contains onRender() Added 
  OrderedRepeatingView extends RepeatingView this renders its 
 children 
  in the order they were added.
  DataView now extends OrderedRepeatingView and 
 onBeginRequest has been 
  reworked to work with or without a IUniqueKeyProvider.
  
  -Igor
  
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of 
   Christian Essl
   Sent: Thursday, August 11, 2005 12:56 PM
   To: wicket-user@lists.sourceforge.net
   Subject: Re: [Wicket-user] DataView: 
 IDataProvider.primaryKey() vote
  
   On Thu, 11 Aug 2005 08:20:06 -0700, Igor Vaynberg 
   [EMAIL PROTECTED]
   wrote:
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of 
Christian Essl
  
Equals() wont work because that wont be able to handle two
   of the same
object in the iterator.
   Good point. You mean in your case of primaryKey an Exception is 
   always thrown, because of the component-id check in the container 
   and in my case not. Good catch this is a bug - thanks. 
 The bug could 
   either be solved by also throwing an Exception or by doing what I 
   think the user rather expects, namely showing all Objects in the 
   iterator (wheter double contained or not) and than making 
 sure that 
   on the next turn the DataItems which share an equal IModel are 
   always removed and potentially recreated.
   I acutally think the second solution can be implemented with very 
   little performance loss.
  
I think the solution would be pretty simple: if you 
 want optimized 
item removal you need to provide the primarykey - maybe 
 we can add 
some stuff to primarykey() params to make it easier.
   
   I am not so keen on optimized item removal. I was more against a 
   mandatory
   primaryKey() mehtod. Than I got tracked into showing that 
 it is not 
   needed.
  
   I know you are short on time so thanks for the rather long 
   discussion, Christian
  
  
  
  
  
   ___
   Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher 
 kostenlos - Hier 
   anmelden: http://mail.yahoo.de
  
  
  
   ---
   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

Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Phil Kulak
-1

If we wanted to get that method out of the DataProvider interface, I
think it would be better to move it into the model:

public interface IDataModel extends IModel {
   public String getPrimaryKey();
}

I just woudn't like relying on an implementation of equals() that may
or may not exst, and the code because less seft documenting.


---
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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Jonathan Locke


i realize i'm jumping into the middle of a conversation i haven't been 
following, but i saw the code below and thought of this:


public interface IDatabaseModel extends IModel
{
   public boolean isSame(IDatabaseModel model);
}

that seems like a nice general way to define sameness between database 
models without knowing how it's implemented.
then maybe create an abstract base class for typical database models 
that define equality in terms of primary keys and/or one that does it in 
terms of Object.equals().
my very limited understanding of hibernate is that you want to define 
Object.equals() in hibernate based on business fields rather than 
primary key.
but in any case, with the contract above, you could push the notion of 
how something is the same out of the contract and into the 
implementation, where it probably belongs...
i don't know.  i may not understand what you're doing.  hope i'm not 
starting a flame war...


 jon

Phil Kulak wrote:


-1

If we wanted to get that method out of the DataProvider interface, I
think it would be better to move it into the model:

public interface IDataModel extends IModel {
  public String getPrimaryKey();
}

I just woudn't like relying on an implementation of equals() that may
or may not exst, and the code because less seft documenting.


---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
We don't and we cant.
-Igor
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Johan Compagner
 Sent: Wednesday, August 10, 2005 12:52 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 how would it work then?
 How do we guarantee that they implement it right?
 
 Igor Vaynberg wrote:
  This is a vote to remove primaryKey() from IDataProvider and use 
  Imodel instance identity in order to provide optimized item 
 removal in 
  the dataview.
 
 
 
 
  ---
  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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
In this case primaryKey() can be a db primary key or a business primary key
since there is a 1-1 mapping. 

Also, I don't think it would make sense to have dataview depending on an
external IDatabaseModel.

-Igor


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Jonathan Locke
 Sent: Wednesday, August 10, 2005 1:13 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 
 i realize i'm jumping into the middle of a conversation i 
 haven't been following, but i saw the code below and thought of this:
 
 public interface IDatabaseModel extends IModel {
 public boolean isSame(IDatabaseModel model); }
 
 that seems like a nice general way to define sameness between 
 database models without knowing how it's implemented.
 then maybe create an abstract base class for typical database 
 models that define equality in terms of primary keys and/or 
 one that does it in terms of Object.equals().
 my very limited understanding of hibernate is that you want to define
 Object.equals() in hibernate based on business fields rather 
 than primary key.
 but in any case, with the contract above, you could push the 
 notion of how something is the same out of the contract and 
 into the implementation, where it probably belongs...
 i don't know.  i may not understand what you're doing.  hope 
 i'm not starting a flame war...
 
   jon
 
 Phil Kulak wrote:
 
 -1
 
 If we wanted to get that method out of the DataProvider interface, I 
 think it would be better to move it into the model:
 
 public interface IDataModel extends IModel {
public String getPrimaryKey();
 }
 
 I just woudn't like relying on an implementation of equals() 
 that may 
 or may not exst, and the code because less seft documenting.
 
 
 ---
 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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Jonathan Locke


i guess i don't precisely understand what you're doing.  if you don't 
want to introduce
a new model type, which seems fine to me... maybe you can still keep 
your component
neutral and general by keeping your method for determining identity on 
the other side of

the interface.  what about:

public interface IDataProvider extends Serializable
{
   Iterator iterator(int first, int count);
   int size();
   IModel model(Object object);
   boolean isSame(Object a, Object b)
}

?

i also don't quite understand the choice of the word Data here...  
isn't this really a TableView
or GridView more than a DataView?  and if you keep the details of 
sorting and key/identity
on the other side of the interface, it would work with things other than 
database objects...


btw, why does model() exist?  couldn't iterator just produce a bunch of 
IModels?  this seems

nice to me...

public interface TableView.IRange
{
   IteratorIModel iterator(int first, int count);
   int size();
   boolean isSame(IModel a, IModel b)
}

how the thing produces IModels and how it determines equality are up to 
the user.
this component could be used to replace listview functionality as well 
as working

with databases... no?

Igor Vaynberg wrote:


In this case primaryKey() can be a db primary key or a business primary key
since there is a 1-1 mapping. 


Also, I don't think it would make sense to have dataview depending on an
external IDatabaseModel.

-Igor


 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
Jonathan Locke

Sent: Wednesday, August 10, 2005 1:13 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote


i realize i'm jumping into the middle of a conversation i 
haven't been following, but i saw the code below and thought of this:


public interface IDatabaseModel extends IModel {
   public boolean isSame(IDatabaseModel model); }

that seems like a nice general way to define sameness between 
database models without knowing how it's implemented.
then maybe create an abstract base class for typical database 
models that define equality in terms of primary keys and/or 
one that does it in terms of Object.equals().

my very limited understanding of hibernate is that you want to define
Object.equals() in hibernate based on business fields rather 
than primary key.
but in any case, with the contract above, you could push the 
notion of how something is the same out of the contract and 
into the implementation, where it probably belongs...
i don't know.  i may not understand what you're doing.  hope 
i'm not starting a flame war...


 jon

Phil Kulak wrote:

   


-1

If we wanted to get that method out of the DataProvider interface, I 
think it would be better to move it into the model:


public interface IDataModel extends IModel {
 public String getPrimaryKey();
}

I just woudn't like relying on an implementation of equals() 
 

that may 
   


or may not exst, and the code because less seft documenting.


---
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

Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Christian Essl

I don't want to start a flame war here too. So my vote is 0.

My suggestion is not based on IModel identity but equality. If users do 
not implement equals/hashCode on the IModel gotten from model(Object) than 
all old DataItems will be removed and newly recreated. DataView will still 
work (less efficient of course). If they implement equals/hasCode 
(correctly) the DataItems with equal IModels will be kept.


The right implementation of equals/hashCode is as much out of the control 
of the framework as the right implementation of primaryKey().


Sorry if I have bothered you. I think currently the vote is clear and we 
should stop this.


Christian

On Wed, 10 Aug 2005 21:51:45 +0200, Johan Compagner [EMAIL PROTECTED] 
wrote:



how would it work then?
How do we guarantee that they implement it right?

Igor Vaynberg wrote:

This is a vote to remove primaryKey() from IDataProvider and use Imodel
instance identity in order to provide optimized item removal in the
dataview.




---
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




--
Christian Essl 






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Wednesday, August 10, 2005 2:06 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 I don't want to start a flame war here too. So my vote is 0.
 
 My suggestion is not based on IModel identity but equality. 
 If users do not implement equals/hashCode on the IModel 
 gotten from model(Object) than all old DataItems will be 
 removed and newly recreated. DataView will still work (less 
 efficient of course). If they implement equals/hasCode
 (correctly) the DataItems with equal IModels will be kept.

The con is that here the understanding of what needs to go into equals and
hashcode is unclear. Also the Imodel is more of a locator rather then the
model itself, it doesn't really make sense to have equals and hashcode for
locators.

 The right implementation of equals/hashCode is as much out of 
 the control of the framework as the right implementation of 
 primaryKey().

Yes you are right, but it's a lot clearer what the function of the
primarykey() is.

 Sorry if I have bothered you. I think currently the vote is 
 clear and we should stop this.

You havent bothered me. The vote is so that we can decide whether or not we
should spend more time to figure out how to do this rather then dropping the
idea entirely.

-Igor




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Jonathan Locke
 Sent: Wednesday, August 10, 2005 2:01 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 
 i guess i don't precisely understand what you're doing. 

Check out DataView.onInternalBeginRequest(). Basically each DataItem needs
to have a unique id as a child of the dataview, currently this id comes from
IDataProvider.primaryKey() - this is an easy way to facilitate optimized
item removal - in the listview the id was the index.

 
 i also don't quite understand the choice of the word Data here...  
 isn't this really a TableView
 or GridView more than a DataView?  and if you keep the 
 details of sorting and key/identity on the other side of the 
 interface, it would work with things other than database objects...

The sorting is already on the other side. There are optional
interfaces/classes that facilitate this.
The Data word was the common denominator - why ListView? Your are
generating tables and grids with that also. DataView is meant to be a
generic loop over data and it does work with things other then databases -
all you need is an iterator.

 
 btw, why does model() exist?  couldn't iterator just produce 
 a bunch of IModels?  this seems nice to me...
 
 public interface TableView.IRange
 {
 IteratorIModel iterator(int first, int count);
 int size();
 boolean isSame(IModel a, IModel b)
 }
 
 how the thing produces IModels and how it determines equality 
 are up to the user.
 this component could be used to replace listview 
 functionality as well as working with databases... no?

Having model(Object o) is more convinient then having to wrap the iterator
you get from your datasource with a decorator.

isSame(imodel a, imodel b) makes it difficult to efficiently check for
existence since you have to loop over each element as opposed to doing a map
or a set lookup once you have the pk.

-Igor




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
Alrite, without spending too much more time on this, entartain this idea:
Move primarykey to IPrimaryKeyProvider { String primaryKey() }

The dataview can do an instanceof check on the impl of IDataProvider, if it
implements iprimarykeyprovider use that otherwise use a generic counter.


-Igor
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Wednesday, August 10, 2005 2:06 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 I don't want to start a flame war here too. So my vote is 0.
 
 My suggestion is not based on IModel identity but equality. 
 If users do not implement equals/hashCode on the IModel 
 gotten from model(Object) than all old DataItems will be 
 removed and newly recreated. DataView will still work (less 
 efficient of course). If they implement equals/hasCode
 (correctly) the DataItems with equal IModels will be kept.
 
 The right implementation of equals/hashCode is as much out of 
 the control of the framework as the right implementation of 
 primaryKey().
 
 Sorry if I have bothered you. I think currently the vote is 
 clear and we should stop this.
 
 Christian
 
 On Wed, 10 Aug 2005 21:51:45 +0200, Johan Compagner 
 [EMAIL PROTECTED]
 wrote:
 
  how would it work then?
  How do we guarantee that they implement it right?
 
  Igor Vaynberg wrote:
  This is a vote to remove primaryKey() from IDataProvider and use 
  Imodel instance identity in order to provide optimized 
 item removal 
  in the dataview.
 
 
 
 
  ---
  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
 
 
 
 --
 Christian Essl 
 
   
 
   
   
 ___
 Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - 
 Hier anmelden: http://mail.yahoo.de
 
 
 
 ---
 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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Jonathan Locke


no, you just write an adaptor...

Johan Compagner wrote:





i also don't quite understand the choice of the word Data here...  
isn't this really a TableView
or GridView more than a DataView?  and if you keep the details of 
sorting and key/identity
on the other side of the interface, it would work with things other 
than database objects...


It is supposed to be an easy DataView for database objects
Else you would just get a ListView...



btw, why does model() exist?  couldn't iterator just produce a bunch 
of IModels?  this seems

nice to me...


If you don't do that then you have to loop twice over everything...
first in the iterator (that just returns directly a hibernate list (or 
whatever db impl you have)


return getContactsDB().find(first, count, firstName, true).iterator();

Then that method would be completely different.
First iterate yourself build up yet another List wrap everything you 
get inside a IModel and then call iterate again on it.




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
Right, we would need to have something like this:

Public abstract class ModelIteratorDecorator {
private Iterator delegate;

...

public boolean hasNext() {
return delegate.hasNext();
}

public Object next() {
return model(delegate.next());
}

public abstract Imodel model(Object o);

...
}

And then in your dataprovider :

public Iterator iterator(int first, int count) {
Iterator it=getiteratorfromdatastore();
return new ModelIteratorDecorator(it) {
public Imodel model(Object o) {
...
}
}

This seems more complicated and more verbouse.

-Igor


 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Jonathan Locke
 Sent: Wednesday, August 10, 2005 3:18 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 
 no, you just write an adaptor...
 
 Johan Compagner wrote:
 
 
 
  i also don't quite understand the choice of the word 
 Data here...  
  isn't this really a TableView
  or GridView more than a DataView?  and if you keep the details of 
  sorting and key/identity on the other side of the 
 interface, it would 
  work with things other than database objects...
 
  It is supposed to be an easy DataView for database objects Else you 
  would just get a ListView...
 
 
  btw, why does model() exist?  couldn't iterator just 
 produce a bunch 
  of IModels?  this seems nice to me...
 
  If you don't do that then you have to loop twice over everything...
  first in the iterator (that just returns directly a 
 hibernate list (or 
  whatever db impl you have)
 
  return getContactsDB().find(first, count, firstName, 
  true).iterator();
 
  Then that method would be completely different.
  First iterate yourself build up yet another List wrap 
 everything you 
  get inside a IModel and then call iterate again on it.
 
 
 
  ---
  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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Phil Kulak
I think people are getting turned off by it being called primaryKey()
because that makes it sound like all you can work from are databases.
It's really not though. It's more like hashCode(), but returning a
String. But if you called it something like stringHashCode(), people
wouldn't know what the hell you were talking about.

Actually, you know what, that gives me an idea:

public abstract class SimpleDataProvider implements IDataProvider {
   public String getPrimaryKey(Object o) {
  return Integer.valueOf(o.hashCode()).toString();
   }
}

Badda bing. ;)

On 8/10/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
 Right, we would need to have something like this:
 
 Public abstract class ModelIteratorDecorator {
 private Iterator delegate;
 
 ...
 
 public boolean hasNext() {
 return delegate.hasNext();
 }
 
 public Object next() {
 return model(delegate.next());
 }
 
 public abstract Imodel model(Object o);
 
 ...
 }
 
 And then in your dataprovider :
 
 public Iterator iterator(int first, int count) {
 Iterator it=getiteratorfromdatastore();
 return new ModelIteratorDecorator(it) {
 public Imodel model(Object o) {
 ...
 }
 }
 
 This seems more complicated and more verbouse.
 
 -Igor
 
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of
  Jonathan Locke
  Sent: Wednesday, August 10, 2005 3:18 PM
  To: wicket-user@lists.sourceforge.net
  Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 
  no, you just write an adaptor...
 
  Johan Compagner wrote:
 
  
  
   i also don't quite understand the choice of the word
  Data here...
   isn't this really a TableView
   or GridView more than a DataView?  and if you keep the details of
   sorting and key/identity on the other side of the
  interface, it would
   work with things other than database objects...
  
   It is supposed to be an easy DataView for database objects Else you
   would just get a ListView...
  
  
   btw, why does model() exist?  couldn't iterator just
  produce a bunch
   of IModels?  this seems nice to me...
  
   If you don't do that then you have to loop twice over everything...
   first in the iterator (that just returns directly a
  hibernate list (or
   whatever db impl you have)
  
   return getContactsDB().find(first, count, firstName,
   true).iterator();
  
   Then that method would be completely different.
   First iterate yourself build up yet another List wrap
  everything you
   get inside a IModel and then call iterate again on it.
  
  
  
   ---
   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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
Definetely not. Hashcode is not required to be unique, different semantic.
-Igor
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Phil Kulak
 Sent: Wednesday, August 10, 2005 5:13 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 I think people are getting turned off by it being called 
 primaryKey() because that makes it sound like all you can 
 work from are databases.
 It's really not though. It's more like hashCode(), but 
 returning a String. But if you called it something like 
 stringHashCode(), people wouldn't know what the hell you were 
 talking about.
 
 Actually, you know what, that gives me an idea:
 
 public abstract class SimpleDataProvider implements IDataProvider {
public String getPrimaryKey(Object o) {
   return Integer.valueOf(o.hashCode()).toString();
}
 }
 
 Badda bing. ;)
 
 On 8/10/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
  Right, we would need to have something like this:
  
  Public abstract class ModelIteratorDecorator {
  private Iterator delegate;
  
  ...
  
  public boolean hasNext() {
  return delegate.hasNext();
  }
  
  public Object next() {
  return model(delegate.next());
  }
  
  public abstract Imodel model(Object o);
  
  ...
  }
  
  And then in your dataprovider :
  
  public Iterator iterator(int first, int count) {
  Iterator it=getiteratorfromdatastore();
  return new ModelIteratorDecorator(it) {
  public Imodel model(Object o) {
  ...
  }
  }
  
  This seems more complicated and more verbouse.
  
  -Igor
  
  
  
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of 
   Jonathan Locke
   Sent: Wednesday, August 10, 2005 3:18 PM
   To: wicket-user@lists.sourceforge.net
   Subject: Re: [Wicket-user] DataView: 
 IDataProvider.primaryKey() vote
  
  
   no, you just write an adaptor...
  
   Johan Compagner wrote:
  
   
   
i also don't quite understand the choice of the word
   Data here...
isn't this really a TableView
or GridView more than a DataView?  and if you keep the 
 details of 
sorting and key/identity on the other side of the
   interface, it would
work with things other than database objects...
   
It is supposed to be an easy DataView for database objects Else 
you would just get a ListView...
   
   
btw, why does model() exist?  couldn't iterator just
   produce a bunch
of IModels?  this seems nice to me...
   
If you don't do that then you have to loop twice over 
 everything...
first in the iterator (that just returns directly a
   hibernate list (or
whatever db impl you have)
   
return getContactsDB().find(first, count, firstName, 
true).iterator();
   
Then that method would be completely different.
First iterate yourself build up yet another List wrap
   everything you
get inside a IModel and then call iterate again on it.
   
   
   
---
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

RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
 
 I think people are getting turned off by it being called 
 primaryKey() because that makes it sound like all you can 
 work from are databases.

What shoud we call it?

-Igor




---
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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Christian Essl
Did entertain myself with the idea and tried to implement it. Attached is 
a roughly tested patch.


I changed the name of IPrimaryKeyProvider to IPrimaryKeyDataProvider.

I also did replace the Map in DataView.onRender() with an array.

Christian

On Wed, 10 Aug 2005 14:35:45 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



Alrite, without spending too much more time on this, entartain this idea:
Move primarykey to IPrimaryKeyProvider { String primaryKey() }

The dataview can do an instanceof check on the impl of IDataProvider, if 
it

implements iprimarykeyprovider use that otherwise use a generic counter.


-Igor

Index: DataView.java
===
RCS file: 
/cvsroot/wicket-stuff/wicket-contrib-dataview/src/wicket/contrib/dataview/DataView.java,v
retrieving revision 1.8
diff -u -r1.8 DataView.java
--- DataView.java   10 Aug 2005 04:55:09 -  1.8
+++ DataView.java   11 Aug 2005 00:51:48 -
@@ -57,6 +57,11 @@
private int cachedItemCount = -1;
 
/**
+* A counter which will be used to generate generic ids for DataItem
+*/
+   private long _idGenerationCounter = 0; //TODO: check if this holds 
enough numbers for unchecked upcount.
+
+   /**
 * @see wicket.Component#Component(String)
 */
public DataView(final String id)
@@ -208,9 +213,74 @@
/**
 * @see wicket.MarkupContainer#internalOnBeginRequest()
 */
-   protected void internalOnBeginRequest()
-   {
+   protected void internalOnBeginRequest(){
final IDataProvider dataProvider = getDataProvider();
+   if (dataProvider instanceof IPrimaryKeyDataProvider) {
+   IPrimaryKeyDataProvider pkp = 
(IPrimaryKeyDataProvider)dataProvider;
+   internalOnBeginRequestPrimaryKey(pkp);
+   }else{
+   internalOnBeginRequestIModel(dataProvider);
+   }
+   }
+
+   private void internalOnBeginRequestIModel(IDataProvider dataProvider)
+   {
+   // Get number of items to be displayed
+   final int size = getViewSize();
+
+   if (size  0)
+   {
+   Iterator it = null;
+
+   Map existingDataItems = new HashMap(size());
+   it = iterator();
+   while (it.hasNext())
+   {
+   final DataItem child = (DataItem)it.next();
+   existingDataItems.put(child.getModel(),child);
+   }
+
+   it = dataProvider.iterator(firstIndex, size);
+
+   // render all items not already present
+   int index = 0;
+   while (it.hasNext()indexsize)
+   {
+   final Object object = it.next();
+   final String id = 
DataViewUniqueName+_idGenerationCounter++;
+   final IModel newModel = 
dataProvider.model(object);
+
+   DataItem item = 
(DataItem)existingDataItems.get(newModel); 
+   if (item == null)
+   {
+   item = newItem(id, index, newModel);
+   add(item);
+   populateItem(item);
+   }
+   else
+   {
+   item.setIndex(index);
+   existingDataItems.remove(newModel);
+   }
+   index++;
+   }
+
+   // remove dataitems no longer present in the view
+   it = existingDataItems.values().iterator();
+   while (it.hasNext())
+   {
+   DataItem item = (DataItem)it.next();
+   remove(item.getId());
+   }
+   }
+   else
+   {
+   removeAll();
+   }
+   }
+
+   private void internalOnBeginRequestPrimaryKey(final 
IPrimaryKeyDataProvider dataProvider)
+   {
 
// Get number of items to be displayed
final int size = getViewSize();
@@ -290,23 +360,31 @@
 
// maybe keep a map like this always updated as a field? what 
about
// versioning?
-   Map itemsByIndex = new HashMap();
+   // just a proposal: (Christian)
+   final int size = getViewSize();
+   DataItem[] itemsByIndex = new DataItem[size];
Iterator it = iterator();
while (it.hasNext())

Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Christian Essl

Maybe uniqueKey()?

On Wed, 10 Aug 2005 17:34:33 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:




I think people are getting turned off by it being called
primaryKey() because that makes it sound like all you can
work from are databases.


What shoud we call it?

-Igor






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
Thanks for the patch.

A couple of comments:
1) I don't like iprimarykeyprovider, or whatever it ends up being called,
extend idataprovider. It can be its own interface that your own impl of
idataprovider can chose to ALSO implement.


2) If we do (1) we can get rid of the duplicate onbeginrequest methods by
using an impl of iprimarykeyprovider that uses the long counter.

On a more general point what do people think about this approach? (splitting
primarykey() into iprimarykeyprovider)

-Igor



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Wednesday, August 10, 2005 6:06 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 Did entertain myself with the idea and tried to implement it. 
 Attached is a roughly tested patch.
 
 I changed the name of IPrimaryKeyProvider to IPrimaryKeyDataProvider.
 
 I also did replace the Map in DataView.onRender() with an array.
 
 Christian
 
 On Wed, 10 Aug 2005 14:35:45 -0700, Igor Vaynberg 
 [EMAIL PROTECTED]
 wrote:
 
  Alrite, without spending too much more time on this, 
 entartain this idea:
  Move primarykey to IPrimaryKeyProvider { String primaryKey() }
 
  The dataview can do an instanceof check on the impl of 
 IDataProvider, 
  if it implements iprimarykeyprovider use that otherwise use 
 a generic 
  counter.
 
 
  -Igor
 
 
 




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
That might work. In my mind primary key is not a database-centric term.
Maybe uniqueKey is better.

Votes?

Im +0

-Igor


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Wednesday, August 10, 2005 6:07 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote
 
 Maybe uniqueKey()?
 
 On Wed, 10 Aug 2005 17:34:33 -0700, Igor Vaynberg 
 [EMAIL PROTECTED]
 wrote:
 
 
  I think people are getting turned off by it being called
  primaryKey() because that makes it sound like all you can 
 work from 
  are databases.
 
  What shoud we call it?
 
  -Igor
 
   
 
   
   
 ___
 Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - 
 Hier anmelden: http://mail.yahoo.de
 
 
 
 ---
 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


Re: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Christian Essl
On Wed, 10 Aug 2005 18:16:35 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



Thanks for the patch.

A couple of comments:
1) I don't like iprimarykeyprovider, or whatever it ends up being called,
extend idataprovider. It can be its own interface that your own impl of
idataprovider can chose to ALSO implement.



That's propably better.



2) If we do (1) we can get rid of the duplicate onbeginrequest methods by
using an impl of iprimarykeyprovider that uses the long counter.

Yes there is a synergy but the current methods are still quite different - 
have to think abaout it. In case we make no model mapping (a removeall for 
no iprimarykeyprovider) than the counter is not realy needed.


Another thing:
Maybe in onRender instead of rendering over the viewSize we could use the 
Component.size(). I thought of this because I am a bit worried about the 
stability of viewSize. With a DB you will generally not read in a 
SERIALIZED transaction, so if someone else removes an entry between 
getItemCount() and the actual iterator-select than you could end up with a 
bigger viewSize than there are items in the iterator - items for 
rendering. I am not sure if this is too much concern any thoughts?


Ok I think for today its enough.

Christian






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
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


RE: [Wicket-user] DataView: IDataProvider.primaryKey() vote

2005-08-10 Thread Igor Vaynberg
  2) If we do (1) we can get rid of the duplicate 
 onbeginrequest methods 
  by using an impl of iprimarykeyprovider that uses the long counter.
 
 Yes there is a synergy but the current methods are still 
 quite different - have to think abaout it. In case we make no 
 model mapping (a removeall for no iprimarykeyprovider) than 
 the counter is not realy needed.

Indeed, simply removeall() and use a local counter for the ids. We can still
wrap it in a iprimarykeyprovider.

 Another thing:
 Maybe in onRender instead of rendering over the viewSize we 
 could use the Component.size(). I thought of this because I 
 am a bit worried about the stability of viewSize. With a DB 
 you will generally not read in a SERIALIZED transaction, so 
 if someone else removes an entry between
 getItemCount() and the actual iterator-select than you could 
 end up with a bigger viewSize than there are items in the 
 iterator - items for rendering. I am not sure if this is too 
 much concern any thoughts?

If we do this we would have to lock the add()/remove()/etc methods in the
dataview.

Or what we can do is record the number of actual dataitems added in
onbeginrequest in a field, and use that in render(). Thoughts?

-Igor




---
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