Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Deleting Rows in TableField not calling store
Deleting Rows in TableField not calling store [message #988884] Mon, 03 December 2012 14:40 Go to next message
Sebastian Boccardi is currently offline Sebastian BoccardiFriend
Messages: 47
Registered: September 2012
Location: Montevideo
Member
When i do this:

protected void execAction() throws ProcessingException {
            for (ITableRow r : getSelectedRows()) {
              deleteRow(r);
            }
            storeStateInternal();    <------- THIS
          }


I had to add the line to call the store of the form, if i don´t do it that way store is not called after deleting rows and clicking OK. Auto discard is on.

Shouldn´t the form be observing the table for any change?

Sebastian
Re: Deleting Rows in TableField not calling store [message #988922 is a reply to message #988884] Mon, 03 December 2012 17:58 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 790
Registered: October 2011
Senior Member
In a Table on the client, you have two ways to delete a row:

* deleteRow(..): the row disappear from Table (as expected by the user), but is still present in the table. You can access it with ITableRow#getDeletedRows(). Later if you export the form content in the formData, you will get row in the table with the status ITableHolder.STATUS_DELETED and you can persist the deletion in the database:

    for (int i = 0; i < formData.getStandardTable().getRowCount(); i++) {
      if (formData.getStandardTable().getRowState(i) == ITableHolder.STATUS_DELETED) {
        //persist the deletion in the database.
      }
    }


I often use a switch on getRowState(), because the action I need depend on the row status:
for (int i = 0; i < table.getRowCount(); i++) {
      switch (table.getRowState(i)) {
        case ITableHolder.STATUS_INSERTED:
          //persist insertion
          break;
        case ITableHolder.STATUS_DELETED:
          //persist deletion
          break;
        case ITableHolder.STATUS_UPDATED:
          //persist modification
          break;
		  case ITableHolder.STATUS_NON_CHANGED:
        default:
          //Do nothing
          break;
      }
    }


* discardRow(..): the row is removed from the table and lost. Nothing is sent to the server.

Now if you set AutoDiscardOnDelete on the table, calling deleteRow(..) is equivalent to discardRow(..).


The semantic of a discarded row is: the row is deleted + there is no modification to commit to the server. The TableField assume there is no modifications. There is no "saveNeeded" status, the user will not be informed that he has pending modifications on the form...

This is why, in your case I recommend to set AutoDiscardOnDelete to false.

---
Now if you still want to discard a row, and to indicate to the form that you have a modification, you can

Now if for any reason you still want to discard a row, and in the same time indicate a pending modification you can:
* Call touch() on the TableField.
* Override the execIsSaveNeeded() on the TableField (this allow you to implement a custom calculation)

If you want to enforce a form store (like a OK or a SAVE button would do), instead of just indicating a modification on the form, I recommend you to call IForm#doSave() instead of AbstractForm#storeStateInternal(). The doSave() method will perform all the other checks (validations, custom checks...) in order to have a clean state of the form (and of the formData).

---

I hope this helps. Do not hesitate to continue the conversation if you need more informations.
Re: Deleting Rows in TableField not calling store [message #988937 is a reply to message #988922] Mon, 03 December 2012 21:06 Go to previous messageGo to next message
Sebastian Boccardi is currently offline Sebastian BoccardiFriend
Messages: 47
Registered: September 2012
Location: Montevideo
Member
Jeremie thank you, everything was very clear. The switch you suggested seems the way to go.

Do you happen to know the what each status mean??? How do you get an INSERTED row?, they are either in NON_CHANGED (even when they are new), DELETED or UPDATED.

It would be great, at least for me, that if a new row is added, even after the user edits some cell or not, the row would be in INSERTED state at the server. So i don´t have to "guess" if the row is new or not.

Re: Deleting Rows in TableField not calling store [message #989003 is a reply to message #988937] Tue, 04 December 2012 09:39 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 790
Registered: October 2011
Senior Member
The API of table in the client offers a lot of functions. In my opinion, 3 ways can be considered:

1: One row, with type check on set value. (you get compile error if you change something in your table):
ITableRow row = getTable().createRow();
getTable().getIntegerColumn().setValue(row, 25);
getTable().getTextColumn().setValue(row, "Dolore");
getTable().addRow(row, true); //true means mark as inserted. If you omit the second parameter, default is false.


2: One row as Object[] array.
getTable().addRowsByArray(
    new Object[]{42, "Amet"}, 
    ITableRow.STATUS_INSERTED); //You can omit the second parameter, default is ITableRow.STATUS_INSERTED.


3: Multiple rows as Object[][] array.
getTable().addRowsByMatrix(new Object[][]{
    new Object[]{57, "Viverra"},
    new Object[]{74, "Gravida"}
}, ITableRow.STATUS_INSERTED); //You can omit the second parameter, default is ITableRow.STATUS_INSERTED.


For the method 2 and 3 you need to be sure that the order of your array elements match with the order of your table columns.
Re: Deleting Rows in TableField not calling store [message #989385 is a reply to message #989003] Wed, 05 December 2012 23:58 Go to previous message
Sebastian Boccardi is currently offline Sebastian BoccardiFriend
Messages: 47
Registered: September 2012
Location: Montevideo
Member
again thank you, it's all clear now
Previous Topic:ServerJob doesn't wait for delay before to reschedule
Next Topic:Corrupted file using IRemoteFileService ...
Goto Forum:
  


Current Time: Sun Nov 23 21:33:59 GMT 2014

Powered by FUDForum. Page generated in 0.02704 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software