Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Don't autoSave when dropping ListGridRecord

    I'm trying to do something very similar to the databound dragging sample:
    http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featured_category

    Except, I want autoSaveEdits to be false on the target grid. I've set it to false and this works for edits performed directly on the ListGrid. When I drop a record from another grid/source, a save message is sent to the server.
    Is it possible to not automatically trigger a server call when a Record is dropped into a ListGrid?

    Please let me know if you need specific version information. I'm writing this from my home computer so I don't have access to the details at the moment, but I can post them later today.

    Thanks.

    #2
    Setting autoSaveEdits to false will not suppress the automatic save from a drag/drop interaction of this kind.
    You'll have to handle this manually in the code - luckily this is very straightforward.

    Add a custom recordDropHandler to the target grid, and in that handler, simply call "setEditValues(...)" passing in the total length of the grid (so the dropped record gets added at the end) and the record properties, extracted from the drop event.

    "cancel" the event to suppress the default drop behavior.

    You may need to call markForRedraw() on the target grid after doing this to update the appearance.

    Comment


      #3
      That works. I had to add some logic to handle events that happen internal to the grid, such as reordering:
      Code:
      final Canvas sourceWidget = event.getSourceWidget();
      final String sourceWidgetID = sourceWidget.getID();
      // targetGrid is defined as a final variable outside the Handler
      if (sourceWidgetID.equals(targetGrid.getID())) {
          return;
      }

      Comment


        #4
        Is there a way to force record components to be drawn? When I drop a new record into the grid this way, the associated component--built by overriding createRecordComponent--is not being created or drawn.

        Comment


          #5
          There is a known limitation of recordComponents that they will not display for unsaved edit values (where there is no underlying record object).

          This is a factor of how they are implemented (they are directly associated with record objects in the data set when they get created).

          If you definitely need record components for unsaved edit-rows in this way, the application could be reworked to achieve it via something like the following:
          - have you listGrid be databound but have the saveLocally flag set to true
          - never perform a fetch against the grid - instead initially populate it via a normal setData([array of records]). You'd possibly have to pick up the data from the DataSource via a fetchData() on that
          - have the drag and drop interaction actually add a record to the list. You could either allow "normal" drag and drop for this, or if you want everything to show up with the "pending edit" styling, you could have a custom drop which adds a new record to the data (with no real attributes set), and then calls setEditValues() to actually populate the edit-values of the record
          - when you want to perform a batch-save of user edits, do this explicitly, by using getAllEditRows() / getEditValues() [or getEditedRecord()] to pick up the array of edits, staring an RPCManager queue, calling dataSource.updateData() for each record, and then doing a send-queue.

          Alternatively, we could get you an estimate for supporting recordComponents with unsaved edit rows directly in the framework. If you'd like us to do that, please contact us offline and we'll get you a quote.

          Regards
          Isomorphic Software

          Comment


            #6
            How to disable automatic save when using
            Code:
            destinationGrid.transferSelectedData(sourceGrid)
            ?
            recordDropHandler() is not called in this case.

            Comment

            Working...
            X