Re: RowEditor and db

[Thomas Leclaire <ze...@gmail.com>]

Hi Greg,

if I well understood, we now have to define explicitly an editor for each
cell of the table.

So I put something like :
        TableViewRowEditor re;
        re = new TableViewRowEditor();
        TextInput editorTextInput = new TextInput();
        editorTextInput.setTextKey("id");
        re.getCellEditors().put("id", editorTextInput);
for each column( here "id") which must be editable.


But why do you not keep the same default behavior but with adding the
default editor to the celleditors list ?
            // Default to a read-only text input editor
            if (editorComponent == null) {
                TextInput editorTextInput = new TextInput();
                editorTextInput.setTextKey(columnName);
                editorComponent = editorTextInput;
                cellEditors.put(columnName, editorComponent);
            }



Also, for get the validation, if I well understood, I have to override the
close method of the tableRowEditor, where I will be able to access new
method getTableView and getRowIndex to have the "old" data, and "new" one
will be accessible via getCellEditors().
It's still not easy to use because it will be necessary to recreate an
object associated with the "new" row in order to compare and process db
modifications. However, I don't think there's some really easy method which
can be automatic for all cases.

I will try to continue on this way.

Thanks,
Thomas



2010/10/28 Greg Brown <gk...@mac.com>

> I have been giving this some thought. While this approach is arguably
> better than the map-based approach, both approaches require the creation of
> a temporary row for validation purposes. This isn't strictly necessary,
> since the data to validate already exists within the editor components.
>
> I think a better approach would be to provide callers with access to the
> editor components. This is consistent with how validation is handled in
> dialogs and sheets, which has historically seemed to work
> well. TableViewRowEditor already has a public getCellEditors() method, and I
> have added a getTextInput() method to ListViewItemEditor and
> TreeViewNodeEditor. I also added accessors for the component being edited
> and the index/path of the value being edited (e.g.
> getTableView()/getRowIndex()).
>
> The only functional change I had to make was how to handle cells that do
> not have an explicitly-defined editor. Previously, TableViewRowEditor would
> create an editable TextInput for these cells. However, there was no way to
> access these editors by column name, so their contents could not be
> validated. Now, TableViewRowEditor will still create these cells, but they
> will be read-only. In other words, if an application wants a cell to be
> editable, an editor component must be specified in the "cellEditors"
> dictionary.
>
> Take a look and let me know what you think.
>
> G
>
> On Oct 27, 2010, at 11:25 AM, Thomas Leclaire wrote:
>
> Hi!
>
> Thanks! I think it's really better.
>
> Maybe just one thing again, I think that classic use of tableRow will be to
> display a list of bean, therefore returning directly the good object in the
> place of the HashMap is maybe better ?
>
> Something like that (don't know if syntax is ok with Pivot standards) :
>
>             Object previewTableRow=null;
>             try {
>                 previewTableRow =
> tableView.getTableData().get(rowIndex).getClass().newInstance();
>             } catch (InstantiationException ex) {
>
> Logger.getLogger(TableViewRowEditor.class.getName()).log(Level.SEVERE, null,
> ex);
>             } catch (IllegalAccessException ex) {
>
> Logger.getLogger(TableViewRowEditor.class.getName()).log(Level.SEVERE, null,
> ex);
>             }
>
>             tablePane.store(previewTableRow);
>
>             valid = validate(previewTableRow, rowIndex);
>
>
> Thanks to such process, we can easily compare 2 objects of same class in
> function validate, and even, by example directly give the object to the db
> persistance layer.
>
> Regards,
> Thomas
>
>
> 2010/10/27 Greg Brown <gk...@mac.com>
>
>> This is done. I also added the rowIndex argument. Let me know how it goes.
>>
>> On Oct 26, 2010, at 9:56 PM, Greg Brown wrote:
>>
>> > Good catch. What we should be doing is calling store() on a new row
>> object, then updating the table data if valid is true. I'll make this
>> change.
>> >
>> > On Oct 26, 2010, at 11:46 AM, Thomas Leclaire wrote:
>> >
>> >> Hi again!
>> >>
>> >> In fact, there are still some problems with this editor!
>> >>
>> >> If we look on method close in TableViewRowEditor :
>> >> if (result) {
>> >>            // Update the row data
>> >>            List<Object> tableData =
>> (List<Object>)tableView.getTableData();//old data
>> >>            Object tableRow = tableData.get(rowIndex);//old data
>> >>
>> >>            tablePane.store(tableRow); //tablePane = new data . it's
>> copied in tableRow.
>> >>
>> >>            valid = validate(tableRow, rowIndex);
>> >>
>> >>            if (valid) {
>> >>                if (tableData.getComparator() == null) {
>> >>                    tableData.update(rowIndex, tableRow);
>> >>                ...
>> >>                }
>> >>            }
>> >>        }
>> >>
>> >>
>> >> There's a problem because the store method provokes the changes in the
>> source data directly.
>> >> tableview is feeded at instanciation of RowEditor with the original
>> table. Therefore, modifications on tableRow are modifications on the
>> original table.
>> >> so call to store method should be done in the if (valid)
>> >> But i'm asking myself what is the need of call method update here like
>> modification was done by method store.
>> >>
>> >>
>> >> Regards,
>> >> Thomas
>> >>
>> >
>>
>>
>
>

Re: RowEditor and db

[Greg Brown <gk...@mac.com>]

> if I well understood, we now have to define explicitly an editor for each cell of the table. 

That is correct.

> But why do you not keep the same default behavior but with adding the default editor to the celleditors list ? 

I considered that, but I think it would be confusing. Seems like it would be doing too much behind the scenes, which we generally try to avoid in Pivot.

> Also, for get the validation, if I well understood, I have to override the close method of the tableRowEditor, where I will be able to access new method getTableView and getRowIndex to have the "old" data, and "new" one will be accessible via getCellEditors(). 

Right.

> It's still not easy to use because it will be necessary to recreate an object associated with the "new" row in order to compare and process db modifications.

That's true if you perform validation by comparing the old row data to the new row data. However, in many cases it is possible to perform validation simply by looking at the contents of any given cell editor (in fact, from my experience, this is fairly common). The current implementation facilitates either approach, which is nice.

G