Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [riena-dev] Table Ridget

I've changed ITableRidget, TableRidget and ListRidget as discussed here and on our call. A few comments:

I) Related to bindToModel(...) there is still one problem case:

columnPropertyNames.length == columnHeader.length != table.getColumnCount()

should also throw a runtime exception. 

The extra benefit of this is, that it also dissalows a special case in SWT, where you can use a Table without any columns: 

Table t = new Table();
addUIControl(...);

Table t a column count of 0 and one "default" column. This default column cannot be accessed (i.e. table.getColumn(0) returns an exception) causing problems in the table ridget. In my opinion it is good to catch and dissalow this case.

The canonical way of using a table ridget should be:

Table t = new Table();
TableColumn tc = new TableColumn(t, ...); // repeat as necessary
addUIControl(...);

As far as I'm concerned this seems acceptable to me.

II) I've made the behavior of the ListRidget similar to the TableRidget regarding sorting, as an effect of allowing listRidget.setSortedColumn(-1):

listRidget.setComparator(0, new StringComparator());
listRidget.setSortedColumn(0); // this was not needed previously

Regards,
Elias.


-----Ursprüngliche Nachricht-----
Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Campo
Gesendet: Monday, June 02, 2008 05:28
An: Riena Developers list
Betreff: Re: [riena-dev] Table Ridget

Hi Elias,
comments below. I discussed the API issues with Carsten.
Am 30.05.2008 um 22:15 schrieb Volanakis, Elias:

> Christian,
>
> a few comments on the ITableRidget interface. We can discuss these
> points on Monday.s
>
> 1. bindToModel(...,String[] columnPropertyNames, String[]
> columnHeaders);
>
> It's not specified what happens when columnPropertyNames.length !=
> columnHeaders.length. My implementation handles this gracefully and
> ignores missing / additional columns. An alternative would be to  
> throw a
> RuntimeException.
>
>
> Should we document this in the interface?

I believe its better to notify the developer of a programming error  
than handle it "gracefully"
which probably does NOT mean the same to everybody. So please throw a  
runtime exception and
note that behaviour in the interface.
>
> 2. bindToModel(..., String[] columnPropertyNames, String[]
> columnHeaders);
>
> Can columnHeaders be null? My implementation allows null on the basis
> that the ListRidget (also implementing ITableRidget) allows null,
> because the List widget does not have headers. This is done in order  
> to
> keep the "handling" of bindToModel similar across different uses  
> making
> it easier for the app developer. If columnHeaders is null, the table
> will have it's headers hidden automatically. (The Swing implementation
> does not allow null.)
>
> We should decide if null is ok and document.

I think null for a single entry in the header is ok (no header for  
that column) and null in
total for all headers (no visible headers for this table) is also ok.  
And yes that should
go into the javadoc.
>
>
> 3. Unsorting a column programmatically:  
> tableRidget.setSortedColumn(-1)
> is not allowed but it still be accomplished using
> tableRidget.setComparator(sortedColumnIndex, null).
>
> Is there a preference one way or the other?
>
We think that calling setComporator(sortedColumnIndex, null) is pretty  
odd and not prefered.
setSortedColumn(-1) looks a lot better even if it might call the other  
method internally.
>
>
> 4. My implementation uses a "creative" way (i.e. unicode char) to  
> show a
> "sortable" indicator in the table header. We should discuss if we want
> to keep this.

I like your "creative" character. Also the way to set the column to  
ascending, descending, not sorted by clicking on
the header is just the prefered way to do this. I think the Swing  
implementation is still missing the unsorted state.
>
>
> 5. My implementation makes all columns moveable by the user by  
> default.
> This may override different settings of the app developer.
>
We should add a method to the Ridget interface to allow or disallow  
moving of columns. "setReorderingAllowed(bool)". We can discuss
the default. I think it should be "false".
> Regards,
> Elias.
>
I talk to you later.....
BTW I checked out the riena.example and the table does not show any  
content (System Properties). Anything I am doing wrong here ?

cheers
christian

_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev


Back to the top