Skip to main content

Row manipulation in DataModel

5 replies [Last post]
rbair
Offline
Joined: 2003-07-08

Hey all,

We've come across a use case for row manipulation in the DataModel (adding rows, removing rows, rearranging rows, etc).

We have a DataModel that contains a row for each phone number associated with a customer. The DataModel is pre-sorted according to the user's preferences (primary phone number listed first, secondary second, etc). The user can change what phone number is their primary phone number, which would then cause a rearranging of rows.

We are also going to need to be able to add and remove rows, of course, for when the customer wants to add phone numbers and/or remove them.

RowSet of course has methods for adding and removing rows, but off the top of my head I don't remember any rearrange methods (moveRow or something of that nature).

I'm in favor of some simple methods like addRecord, removeRecord/deleteRecord, and moveRecord(int newIndex).

Thoughts?

Rich

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Patrick Wright

Some thoughts

1) Nice to have new/updated/deleted rows flagged as such so one can handle
them separately when persisting

2) Deleted/removed--simple option of course is to just remove them from
the underlying model, but if persistence is deferred until the user hits
Save, nice to have the row still around in some fashion. Lots of ways to
do that--keep a separate encapsulated model for deleted rows, for example.

3) You mentioned moveRecord(index)--the concept of index maybe needs to be
fleshed out..? Basic question would be--is the index just the current
physical index in the list of rows in the model? Or is it a logical index?
I load the model, have rows 0-99. I then filter. Is index 15 in the
original set still 15 if the filter is removed? What happens if I insert a
row at position 10 when filtered and then remove the filter?

Patrick

> Hey all,
>
> We've come across a use case for row manipulation in the DataModel (adding
> rows, removing rows, rearranging rows, etc).
>
> We have a DataModel that contains a row for each phone number associated
> with a customer. The DataModel is pre-sorted according to the user's
> preferences (primary phone number listed first, secondary second, etc).
> The user can change what phone number is their primary phone number, which
> would then cause a rearranging of rows.
>
> We are also going to need to be able to add and remove rows, of course,
> for when the customer wants to add phone numbers and/or remove them.
>
> RowSet of course has methods for adding and removing rows, but off the top
> of my head I don't remember any rearrange methods (moveRow or something of
> that nature).
>
> I'm in favor of some simple methods like addRecord,
> removeRecord/deleteRecord, and moveRecord(int newIndex).
>
> Thoughts?
>
> Rich
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=24560忰
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

Hey Patrick

The first two points are right on. If done right undo functionality is only a step away.

> 3) You mentioned moveRecord(index)--the concept of
> index maybe needs to be
> fleshed out..? Basic question would be--is the index
> just the current
> physical index in the list of rows in the model? Or
> is it a logical index?
> I load the model, have rows 0-99. I then filter. Is
> index 15 in the
> original set still 15 if the filter is removed? What
> happens if I insert a
> row at position 10 when filtered and then remove the
> filter?

This is a good point. Rather than a moveRecordIndex it may make more sense to support filters instead. Perhaps the same kind of filters used by the JXTable (Ramesh?)?

Richard

Message was edited by: rbair

rameshgupta
Offline
Joined: 2004-06-04

> RowSet of course has methods for adding and removing
> rows, but off the top of my head I don't remember any
> rearrange methods (moveRow or something of that nature).

RowSet does not have rearrange methods because rowsets are unordered -- They are result "sets", not "lists" :-)

> > 3) You mentioned moveRecord(index)--the concept of
> > index maybe needs to be
> > fleshed out..? Basic question would be--is the
> > index just the current physical index in the list
> > of rows in the model? Or is it a logical index?
> > I load the model, have rows 0-99. I then filter.
> > Is index 15 in the original set still 15 if
> > the filter is removed?

Filters do not change the order of records in the original model. They only change the *apparent* order in the view (JXTable) by vectoring all model access through a redirection index maintained by the filter. So, index 15 in the original set is still 15 if you ask the model, but it might be something else if you ask the view. You can easily convert from model index to view index and vice-versa using JXTable methods.

> > What happens if I insert a row at position 10
> > when filtered and then remove the filter?

If your model is mutable, the row will be added at position 10, regardless of whether the view is filtered or not. Likewise, removing the filter from the view will have no effect on the order of the record in the model.

> This is a good point. Rather than a moveRecordIndex
> it may make more sense to support filters instead.
> Perhaps the same kind of filters used by the JXTable
> (Ramesh?)?
>
> Richard

Hi Richard,

Whether you want to keep your model sorted or not depends entirely on your needs. In some cases, it might make sense to keep your records sorted (e.g., if you want to use binary search on the model). In that case, you will have to make sure that inserting new rows in the model will leave your model in a sorted state.

Most of the time, however, users don't care what the order of records in the model is. All they care is that the records are presented to them in a certain order -- and most of the time, they are the ones who determine what that order should be. For such fickle-minded users, you are better off relying on filters to do the sorting for you.

The choice is yours :-)

Ramesh

rbair
Offline
Joined: 2003-07-08

Hi Ramesh,

I can't think of any situation where gui level filtering would not be adequate. If I come up with a use case, I'll let ya know :-)

Do we have any filtering for JXList? The filtering must support both sorting and exclusion.

Richard

PS> I'm going to file an RFE for addRecord/deleteRecord methods on the DataModel

Message was edited by: rbair

rameshgupta
Offline
Joined: 2004-06-04

> Do we have any filtering for JXList?
> The filtering must support both sorting and exclusion.
>
> Richard

Almost :-)

All data-visualization components (JXList, JXTable, JXTree, and JXTreeTable) share the same filtering, sorting, and highlighting infrastructure. The idea is to avoid repeating one of Swing's mistakes (that of requiring developers to define component-specific renderers and editors).

Instead, we now use component-specific adapters that are package private to Swing/X, so developers don't have to know about them. These adapters (JXList.ListAdapter, JXTable.TableAdapter, and so on) mediate access to the component model and filters.

As for filtering and sorting support in JXList, the framework is already in place (Please see JXList.ListAdapter). The things that remain unimplemented are a handful of methods in the adapter class (look for @todo) -- These methods should folow the general pattern in corresponding methods of JXTable.TableAdapter.

Also, while JTable provides cover methods for accessing data from TableModel (e.g., getRowCount, getValueAt, ...), JList does not have similar cover methods for ListModel methods (getSize and getElementAt). To get a filtered view, developers must not access the model directly, but through the view. So, the only other thing left is providing these simple cover methods in JXList.

Looking for volunteers ;-)

>
> PS> I'm going to file an RFE for
> addRecord/deleteRecord methods on the DataModel

Sure.

Ramesh