You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Thomas Leclaire <ze...@gmail.com> on 2010/10/13 15:16:31 UTC
RowEditor and db
Hi,
I try to use the rowEditor example with a database.
I have no problem to get data from my db (as a List<MyObject>) and display
it in a tableview defined in bxml.
Thanks to the example, I can also edit this data in the display window.
But obviously, modifications are not automatically done in db.
Is there an easy way to get the "modification event" (when row is validated
by user) to process to the modification in db ?
Thanks for help,
Thomas
Re: RowEditor and db
Posted by 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
Re: RowEditor and db
Posted by 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
Posted by 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
Posted by Thomas Leclaire <ze...@gmail.com>.
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
Posted by 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
Posted by Greg Brown <gk...@mac.com>.
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
Posted by Thomas Leclaire <ze...@gmail.com>.
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
Posted by Thomas Leclaire <ze...@gmail.com>.
Yes, this method is good!
In order to be complete, I think that rowIndex should also be accessible in
order to proceed some comparisons with "old" Data.
So this method should be
protected boolean validate(Object tableRow, int rowIndex) {
return true;
}
2010/10/26 Greg Brown <gk...@mac.com>
> I added a validate() method to TableViewRowEditor that you can override to
> prevent closing. The single argument contains the row data to save. If the
> method returns true, the editor will be closed; otherwise, it will remain
> open.
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
Good point. The mechanics of validating a dialog, though similar, are slightly different than for a row editor, since the dialog contents are generally fixed and accessible to the validation logic.
I added a validate() method to TableViewRowEditor that you can override to prevent closing. The single argument contains the row data to save. If the method returns true, the editor will be closed; otherwise, it will remain open.
On Oct 26, 2010, at 7:54 AM, Thomas Leclaire wrote:
> Hi,
>
> Sorry, I didn't have any time to see your answer before today.
>
> In fact, ok it's easier to use and to understand with this simple edit method.
> However, it's still really complicated to process with db modifications.
>
> If I well understood, I have to create a rowEditor when I create my global table and override the close method to process with db modifications.
>
> public void initialize(Map<String, Object> map, URL url, Resources rsrcs) {
> TableViewRowEditor re;
> re = new TableViewRowEditor(){
> @Override
> public void close(boolean result) {
> ...
> }
>
> However, in a such close method, we can't access to rowEditor data, and therefore we can't access to the modification, so it's impossible to process to db updates, neither to compare new and old data.
> There's a cellEditors which is accessible but it seems to be never used (didn't find any assignation).
>
> Regards,
> Thomas
Re: RowEditor and db
Posted by Thomas Leclaire <ze...@gmail.com>.
Hi,
Sorry, I didn't have any time to see your answer before today.
In fact, ok it's easier to use and to understand with this simple edit
method.
However, it's still really complicated to process with db modifications.
If I well understood, I have to create a rowEditor when I create my global
table and override the close method to process with db modifications.
public void initialize(Map<String, Object> map, URL url, Resources rsrcs) {
TableViewRowEditor re;
re = new TableViewRowEditor(){
@Override
public void close(boolean result) {
...
}
However, in a such close method, we can't access to rowEditor data, and
therefore we can't access to the modification, so it's impossible to process
to db updates, neither to compare new and old data.
There's a cellEditors which is accessible but it seems to be never used
(didn't find any assignation).
Regards,
Thomas
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
> Just to make sure I understand the change, this means that in order to (a) get notified when the changes are actually saved to the model or (b) to perform any validation, you'd subclass a stock editor to get hooks into those window events?
Right. If your editor extends Window, you can override close() directly. If the editor contains a window, you can listen for window state events.
> If so, sounds good to me. I just want to make sure this change doesn't reduce the usefulness of the stock editors.
I think the stock editors will still be useful. They provide a base class for applications to extend, which saves the app developer the trouble of writing that code themselves.
I attached the latest versions of ListViewItemEditor and TreeViewNodeEditor in case anyone wants to take a look.
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
> Just to make sure I understand the change, this means that in order to (a) get notified when the changes are actually saved to the model or (b) to perform any validation, you'd subclass a stock editor to get hooks into those window events?
Right. If your editor extends Window, you can override close() directly. If the editor contains a window, you can listen for window state events.
> If so, sounds good to me. I just want to make sure this change doesn't reduce the usefulness of the stock editors.
I think the stock editors will still be useful. They provide a base class for applications to extend, which saves the app developer the trouble of writing that code themselves.
I attached the latest versions of ListViewItemEditor and TreeViewNodeEditor in case anyone wants to take a look.
Re: RowEditor and db
Posted by Todd Volkert <tv...@gmail.com>.
Just to make sure I understand the change, this means that in order to (a)
get notified when the changes are actually saved to the model or (b) to
perform any validation, you'd subclass a stock editor to get hooks into
those window events?
If so, sounds good to me. I just want to make sure this change doesn't
reduce the usefulness of the stock editors.
-T
On Thu, Oct 14, 2010 at 2:38 PM, Greg Brown <gk...@mac.com> wrote:
> Not that I can see.
>
> On Oct 14, 2010, at 2:26 PM, Todd Volkert wrote:
>
> Is there any loss of functionality over the old API?
>
> On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
>
>> I just validated this approach with TableView.RowEditor. I ran into some
>> minor issues with non-text cell editors, but I don't think they are related
>> to the API change (probably just some error in my code - I ported the class
>> pretty quickly). Todd can probably resolve them pretty quickly.
>>
>> At this point, I'm pretty confident that this change is worth making. Any
>> additional comments?
>>
>>
>> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>>
>> > FYI, I have applied this approach to TreeView and it seems to work fine
>> - I'll try updating TableView next.
>> >
>> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
>> >
>> >> I just looked into this a bit more closely. I definitely see what you
>> mean about the ease of use issue - I think the current editor API is
>> probably a bit more complex than it needs to be.
>> >>
>> >> I just prototyped a simpler version for ListView.ItemEditor that I
>> think will also work for TableView and TreeView (as well as ListButton and
>> Spinner, which don't currently support editors but should). The updated
>> interface consists of a single method:
>> >>
>> >> public interface ItemEditor {
>> >> public void edit(ListView listView, int itemIndex);
>> >> }
>> >>
>> >> This simplified interface obviously makes it much easier to implement
>> custom editors. The default ListViewItemEditor class now extends Window and
>> implements ListView.ItemEditor (see attached). The implementation of the
>> edit() method simply sets up the editor and calls the base open() method to
>> show the popup. It overrides close() to update the list data.
>> >>
>> >> By default, the editor does not perform any validation. However, this
>> can easily be applied at the application level by overriding the
>> close(boolean) method. This approach is consistent with other means of
>> collecting user input in a Pivot application (e.g. dialogs and sheets),
>> which also often override close() to perform validation.
>> >>
>> >> An application could also override close() to perform DB updates.
>> Alternatively, this could be done in response to change events fired by the
>> model. Which approach is best depends on the requirements of the
>> application.
>> >>
>> >> TableView's editor interface would look like this:
>> >>
>> >> public interface RowEditor {
>> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
>> >> }
>> >>
>> >> and TreeView's like this:
>> >>
>> >> public interface NodeEditor {
>> >> public void edit(TreeView treeView, Path path);
>> >> }
>> >>
>> >> Comments are welcome.
>> >>
>> >> G
>> >>
>> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>> >>
>> >>>> After writing this, I think I should rather write a jira ticket!
>> >>>
>> >>> That's a good idea. It sounds like you might have some good ideas as
>> to how the editing process could be improved, and JIRA is the best way to
>> track issues like this.
>> >>>
>> >>> G
>> >>>
>> >>
>> >
>>
>>
>
>
Re: RowEditor and db
Posted by Todd Volkert <tv...@gmail.com>.
Just to make sure I understand the change, this means that in order to (a)
get notified when the changes are actually saved to the model or (b) to
perform any validation, you'd subclass a stock editor to get hooks into
those window events?
If so, sounds good to me. I just want to make sure this change doesn't
reduce the usefulness of the stock editors.
-T
On Thu, Oct 14, 2010 at 2:38 PM, Greg Brown <gk...@mac.com> wrote:
> Not that I can see.
>
> On Oct 14, 2010, at 2:26 PM, Todd Volkert wrote:
>
> Is there any loss of functionality over the old API?
>
> On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
>
>> I just validated this approach with TableView.RowEditor. I ran into some
>> minor issues with non-text cell editors, but I don't think they are related
>> to the API change (probably just some error in my code - I ported the class
>> pretty quickly). Todd can probably resolve them pretty quickly.
>>
>> At this point, I'm pretty confident that this change is worth making. Any
>> additional comments?
>>
>>
>> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>>
>> > FYI, I have applied this approach to TreeView and it seems to work fine
>> - I'll try updating TableView next.
>> >
>> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
>> >
>> >> I just looked into this a bit more closely. I definitely see what you
>> mean about the ease of use issue - I think the current editor API is
>> probably a bit more complex than it needs to be.
>> >>
>> >> I just prototyped a simpler version for ListView.ItemEditor that I
>> think will also work for TableView and TreeView (as well as ListButton and
>> Spinner, which don't currently support editors but should). The updated
>> interface consists of a single method:
>> >>
>> >> public interface ItemEditor {
>> >> public void edit(ListView listView, int itemIndex);
>> >> }
>> >>
>> >> This simplified interface obviously makes it much easier to implement
>> custom editors. The default ListViewItemEditor class now extends Window and
>> implements ListView.ItemEditor (see attached). The implementation of the
>> edit() method simply sets up the editor and calls the base open() method to
>> show the popup. It overrides close() to update the list data.
>> >>
>> >> By default, the editor does not perform any validation. However, this
>> can easily be applied at the application level by overriding the
>> close(boolean) method. This approach is consistent with other means of
>> collecting user input in a Pivot application (e.g. dialogs and sheets),
>> which also often override close() to perform validation.
>> >>
>> >> An application could also override close() to perform DB updates.
>> Alternatively, this could be done in response to change events fired by the
>> model. Which approach is best depends on the requirements of the
>> application.
>> >>
>> >> TableView's editor interface would look like this:
>> >>
>> >> public interface RowEditor {
>> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
>> >> }
>> >>
>> >> and TreeView's like this:
>> >>
>> >> public interface NodeEditor {
>> >> public void edit(TreeView treeView, Path path);
>> >> }
>> >>
>> >> Comments are welcome.
>> >>
>> >> G
>> >>
>> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>> >>
>> >>>> After writing this, I think I should rather write a jira ticket!
>> >>>
>> >>> That's a good idea. It sounds like you might have some good ideas as
>> to how the editing process could be improved, and JIRA is the best way to
>> track issues like this.
>> >>>
>> >>> G
>> >>>
>> >>
>> >
>>
>>
>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
Not that I can see.
On Oct 14, 2010, at 2:26 PM, Todd Volkert wrote:
> Is there any loss of functionality over the old API?
>
> On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
> I just validated this approach with TableView.RowEditor. I ran into some minor issues with non-text cell editors, but I don't think they are related to the API change (probably just some error in my code - I ported the class pretty quickly). Todd can probably resolve them pretty quickly.
>
> At this point, I'm pretty confident that this change is worth making. Any additional comments?
>
>
> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>
> > FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
> >
> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> >
> >> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
> >>
> >> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
> >>
> >> public interface ItemEditor {
> >> public void edit(ListView listView, int itemIndex);
> >> }
> >>
> >> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
> >>
> >> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
> >>
> >> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
> >>
> >> TableView's editor interface would look like this:
> >>
> >> public interface RowEditor {
> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
> >> }
> >>
> >> and TreeView's like this:
> >>
> >> public interface NodeEditor {
> >> public void edit(TreeView treeView, Path path);
> >> }
> >>
> >> Comments are welcome.
> >>
> >> G
> >>
> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
> >>
> >>>> After writing this, I think I should rather write a jira ticket!
> >>>
> >>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
> >>>
> >>> G
> >>>
> >>
> >
>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
Not that I can see.
On Oct 14, 2010, at 2:26 PM, Todd Volkert wrote:
> Is there any loss of functionality over the old API?
>
> On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
> I just validated this approach with TableView.RowEditor. I ran into some minor issues with non-text cell editors, but I don't think they are related to the API change (probably just some error in my code - I ported the class pretty quickly). Todd can probably resolve them pretty quickly.
>
> At this point, I'm pretty confident that this change is worth making. Any additional comments?
>
>
> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>
> > FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
> >
> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> >
> >> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
> >>
> >> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
> >>
> >> public interface ItemEditor {
> >> public void edit(ListView listView, int itemIndex);
> >> }
> >>
> >> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
> >>
> >> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
> >>
> >> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
> >>
> >> TableView's editor interface would look like this:
> >>
> >> public interface RowEditor {
> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
> >> }
> >>
> >> and TreeView's like this:
> >>
> >> public interface NodeEditor {
> >> public void edit(TreeView treeView, Path path);
> >> }
> >>
> >> Comments are welcome.
> >>
> >> G
> >>
> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
> >>
> >>>> After writing this, I think I should rather write a jira ticket!
> >>>
> >>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
> >>>
> >>> G
> >>>
> >>
> >
>
>
Re: RowEditor and db
Posted by Todd Volkert <tv...@gmail.com>.
Is there any loss of functionality over the old API?
On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
> I just validated this approach with TableView.RowEditor. I ran into some
> minor issues with non-text cell editors, but I don't think they are related
> to the API change (probably just some error in my code - I ported the class
> pretty quickly). Todd can probably resolve them pretty quickly.
>
> At this point, I'm pretty confident that this change is worth making. Any
> additional comments?
>
>
> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>
> > FYI, I have applied this approach to TreeView and it seems to work fine -
> I'll try updating TableView next.
> >
> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> >
> >> I just looked into this a bit more closely. I definitely see what you
> mean about the ease of use issue - I think the current editor API is
> probably a bit more complex than it needs to be.
> >>
> >> I just prototyped a simpler version for ListView.ItemEditor that I think
> will also work for TableView and TreeView (as well as ListButton and
> Spinner, which don't currently support editors but should). The updated
> interface consists of a single method:
> >>
> >> public interface ItemEditor {
> >> public void edit(ListView listView, int itemIndex);
> >> }
> >>
> >> This simplified interface obviously makes it much easier to implement
> custom editors. The default ListViewItemEditor class now extends Window and
> implements ListView.ItemEditor (see attached). The implementation of the
> edit() method simply sets up the editor and calls the base open() method to
> show the popup. It overrides close() to update the list data.
> >>
> >> By default, the editor does not perform any validation. However, this
> can easily be applied at the application level by overriding the
> close(boolean) method. This approach is consistent with other means of
> collecting user input in a Pivot application (e.g. dialogs and sheets),
> which also often override close() to perform validation.
> >>
> >> An application could also override close() to perform DB updates.
> Alternatively, this could be done in response to change events fired by the
> model. Which approach is best depends on the requirements of the
> application.
> >>
> >> TableView's editor interface would look like this:
> >>
> >> public interface RowEditor {
> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
> >> }
> >>
> >> and TreeView's like this:
> >>
> >> public interface NodeEditor {
> >> public void edit(TreeView treeView, Path path);
> >> }
> >>
> >> Comments are welcome.
> >>
> >> G
> >>
> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
> >>
> >>>> After writing this, I think I should rather write a jira ticket!
> >>>
> >>> That's a good idea. It sounds like you might have some good ideas as to
> how the editing process could be improved, and JIRA is the best way to track
> issues like this.
> >>>
> >>> G
> >>>
> >>
> >
>
>
Re: RowEditor and db
Posted by Todd Volkert <tv...@gmail.com>.
Is there any loss of functionality over the old API?
On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gk...@mac.com> wrote:
> I just validated this approach with TableView.RowEditor. I ran into some
> minor issues with non-text cell editors, but I don't think they are related
> to the API change (probably just some error in my code - I ported the class
> pretty quickly). Todd can probably resolve them pretty quickly.
>
> At this point, I'm pretty confident that this change is worth making. Any
> additional comments?
>
>
> On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
>
> > FYI, I have applied this approach to TreeView and it seems to work fine -
> I'll try updating TableView next.
> >
> > On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> >
> >> I just looked into this a bit more closely. I definitely see what you
> mean about the ease of use issue - I think the current editor API is
> probably a bit more complex than it needs to be.
> >>
> >> I just prototyped a simpler version for ListView.ItemEditor that I think
> will also work for TableView and TreeView (as well as ListButton and
> Spinner, which don't currently support editors but should). The updated
> interface consists of a single method:
> >>
> >> public interface ItemEditor {
> >> public void edit(ListView listView, int itemIndex);
> >> }
> >>
> >> This simplified interface obviously makes it much easier to implement
> custom editors. The default ListViewItemEditor class now extends Window and
> implements ListView.ItemEditor (see attached). The implementation of the
> edit() method simply sets up the editor and calls the base open() method to
> show the popup. It overrides close() to update the list data.
> >>
> >> By default, the editor does not perform any validation. However, this
> can easily be applied at the application level by overriding the
> close(boolean) method. This approach is consistent with other means of
> collecting user input in a Pivot application (e.g. dialogs and sheets),
> which also often override close() to perform validation.
> >>
> >> An application could also override close() to perform DB updates.
> Alternatively, this could be done in response to change events fired by the
> model. Which approach is best depends on the requirements of the
> application.
> >>
> >> TableView's editor interface would look like this:
> >>
> >> public interface RowEditor {
> >> public void edit(TableView tableView, int rowIndex, int columnIndex);
> >> }
> >>
> >> and TreeView's like this:
> >>
> >> public interface NodeEditor {
> >> public void edit(TreeView treeView, Path path);
> >> }
> >>
> >> Comments are welcome.
> >>
> >> G
> >>
> >> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
> >>
> >>>> After writing this, I think I should rather write a jira ticket!
> >>>
> >>> That's a good idea. It sounds like you might have some good ideas as to
> how the editing process could be improved, and JIRA is the best way to track
> issues like this.
> >>>
> >>> G
> >>>
> >>
> >
>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
I just validated this approach with TableView.RowEditor. I ran into some minor issues with non-text cell editors, but I don't think they are related to the API change (probably just some error in my code - I ported the class pretty quickly). Todd can probably resolve them pretty quickly.
At this point, I'm pretty confident that this change is worth making. Any additional comments?
On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
> FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
>
> On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
>
>> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
>>
>> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
>>
>> public interface ItemEditor {
>> public void edit(ListView listView, int itemIndex);
>> }
>>
>> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
>>
>> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
>>
>> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
>>
>> TableView's editor interface would look like this:
>>
>> public interface RowEditor {
>> public void edit(TableView tableView, int rowIndex, int columnIndex);
>> }
>>
>> and TreeView's like this:
>>
>> public interface NodeEditor {
>> public void edit(TreeView treeView, Path path);
>> }
>>
>> Comments are welcome.
>>
>> G
>>
>> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>>
>>>> After writing this, I think I should rather write a jira ticket!
>>>
>>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>>>
>>> G
>>>
>>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
I just validated this approach with TableView.RowEditor. I ran into some minor issues with non-text cell editors, but I don't think they are related to the API change (probably just some error in my code - I ported the class pretty quickly). Todd can probably resolve them pretty quickly.
At this point, I'm pretty confident that this change is worth making. Any additional comments?
On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:
> FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
>
> On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
>
>> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
>>
>> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
>>
>> public interface ItemEditor {
>> public void edit(ListView listView, int itemIndex);
>> }
>>
>> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
>>
>> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
>>
>> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
>>
>> TableView's editor interface would look like this:
>>
>> public interface RowEditor {
>> public void edit(TableView tableView, int rowIndex, int columnIndex);
>> }
>>
>> and TreeView's like this:
>>
>> public interface NodeEditor {
>> public void edit(TreeView treeView, Path path);
>> }
>>
>> Comments are welcome.
>>
>> G
>>
>> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>>
>>>> After writing this, I think I should rather write a jira ticket!
>>>
>>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>>>
>>> G
>>>
>>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
>
> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
>
> public interface ItemEditor {
> public void edit(ListView listView, int itemIndex);
> }
>
> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
>
> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
>
> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
>
> TableView's editor interface would look like this:
>
> public interface RowEditor {
> public void edit(TableView tableView, int rowIndex, int columnIndex);
> }
>
> and TreeView's like this:
>
> public interface NodeEditor {
> public void edit(TreeView treeView, Path path);
> }
>
> Comments are welcome.
>
> G
>
> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>
>>> After writing this, I think I should rather write a jira ticket!
>>
>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>>
>> G
>>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
FYI, I have applied this approach to TreeView and it seems to work fine - I'll try updating TableView next.
On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
>
> I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
>
> public interface ItemEditor {
> public void edit(ListView listView, int itemIndex);
> }
>
> This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
>
> By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
>
> An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
>
> TableView's editor interface would look like this:
>
> public interface RowEditor {
> public void edit(TableView tableView, int rowIndex, int columnIndex);
> }
>
> and TreeView's like this:
>
> public interface NodeEditor {
> public void edit(TreeView treeView, Path path);
> }
>
> Comments are welcome.
>
> G
>
> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>
>>> After writing this, I think I should rather write a jira ticket!
>>
>> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>>
>> G
>>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
public interface ItemEditor {
public void edit(ListView listView, int itemIndex);
}
This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
TableView's editor interface would look like this:
public interface RowEditor {
public void edit(TableView tableView, int rowIndex, int columnIndex);
}
and TreeView's like this:
public interface NodeEditor {
public void edit(TreeView treeView, Path path);
}
Comments are welcome.
G
On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>> After writing this, I think I should rather write a jira ticket!
>
> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>
> G
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
I just looked into this a bit more closely. I definitely see what you mean about the ease of use issue - I think the current editor API is probably a bit more complex than it needs to be.
I just prototyped a simpler version for ListView.ItemEditor that I think will also work for TableView and TreeView (as well as ListButton and Spinner, which don't currently support editors but should). The updated interface consists of a single method:
public interface ItemEditor {
public void edit(ListView listView, int itemIndex);
}
This simplified interface obviously makes it much easier to implement custom editors. The default ListViewItemEditor class now extends Window and implements ListView.ItemEditor (see attached). The implementation of the edit() method simply sets up the editor and calls the base open() method to show the popup. It overrides close() to update the list data.
By default, the editor does not perform any validation. However, this can easily be applied at the application level by overriding the close(boolean) method. This approach is consistent with other means of collecting user input in a Pivot application (e.g. dialogs and sheets), which also often override close() to perform validation.
An application could also override close() to perform DB updates. Alternatively, this could be done in response to change events fired by the model. Which approach is best depends on the requirements of the application.
TableView's editor interface would look like this:
public interface RowEditor {
public void edit(TableView tableView, int rowIndex, int columnIndex);
}
and TreeView's like this:
public interface NodeEditor {
public void edit(TreeView treeView, Path path);
}
Comments are welcome.
G
On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>> After writing this, I think I should rather write a jira ticket!
>
> That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
>
> G
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
> After writing this, I think I should rather write a jira ticket!
That's a good idea. It sounds like you might have some good ideas as to how the editing process could be improved, and JIRA is the best way to track issues like this.
G
Re: RowEditor and db
Posted by Thomas Leclaire <ze...@gmail.com>.
Hi!
In fact, it's not really easy to use. There are several things which
prevents to use easily these listeners to process modification on db.
Firstly, changesSaved or itemUpdated are always fired, even if there is no
changes which were effectively done, it's not really logic. Method
"previewSaveChanges" in RowEditorListener should test if a modification was
really done before to vote Approve.
Secondly, changesSaved has a parameter "columnIndex", but it consider only
the input column, but when we are in roweditMode, we can change all columns.
Maybe have an array with all modified columns could be a good thing in order
to have easily the list of columns which was modified during the edition.
I have more difficulties to see how implement a such system. Nevertheless, I
think the best place is in "previewSaveChanges" in RowEditorListener.
Indeed, the previewSaveChange method can fire the db modification and if
it's not effective physically in db, it's normal to reject the modification
on the display. However, I don't know how the system can react due to
latency delay inherent to database process.
After writing this, I think I should rather write a jira ticket!
Bye,
Thomas
2010/10/14 Greg Brown <gk...@mac.com>
> I'm not intimately familiar with that code, but I believe you can listen
> for TableView.RowEditor#changesSaved() on the row editor. You could also
> listen for ListListener#itemUpdated() on your model.
>
> On Oct 13, 2010, at 9:16 AM, Thomas Leclaire wrote:
>
> > Hi,
> >
> > I try to use the rowEditor example with a database.
> >
> > I have no problem to get data from my db (as a List<MyObject>) and
> display it in a tableview defined in bxml.
> > Thanks to the example, I can also edit this data in the display window.
> >
> > But obviously, modifications are not automatically done in db.
> > Is there an easy way to get the "modification event" (when row is
> validated by user) to process to the modification in db ?
> >
> >
> > Thanks for help,
> > Thomas
>
>
Re: RowEditor and db
Posted by Greg Brown <gk...@mac.com>.
I'm not intimately familiar with that code, but I believe you can listen for TableView.RowEditor#changesSaved() on the row editor. You could also listen for ListListener#itemUpdated() on your model.
On Oct 13, 2010, at 9:16 AM, Thomas Leclaire wrote:
> Hi,
>
> I try to use the rowEditor example with a database.
>
> I have no problem to get data from my db (as a List<MyObject>) and display it in a tableview defined in bxml.
> Thanks to the example, I can also edit this data in the display window.
>
> But obviously, modifications are not automatically done in db.
> Is there an easy way to get the "modification event" (when row is validated by user) to process to the modification in db ?
>
>
> Thanks for help,
> Thomas