FileItem + operationId in DynamicForm issue / bug

[sunnyl]

1. SmartGWT version: v8.3p_2013-03-17/PowerEdition Deployment 2013-03-17
2. Browser: FF 19 dev mode

I have a DynamicForm with a simple vertical layout: a FileItem, a ButtonItem, and a CanvasItem which contains an Img. This DynamicForms is backed by a vanilla SQLDataSource.

This DynamicForm can be told to "fetch" an image from the database and load it into the Img.

The user can use the FileItem to upload a new photo, the process of which is fired by the ButtonItem, however due to the business logic I'm running, both update and add operations go through a DMI such that any new uploads into the database are marked "temporary". This way the new upload will not linked to the parent object until the parent object is saved. Essentially, parent_id in the photo table is null until the parent object is saved and if the user cancels from the modal dialog the newly uploaded photo in the database is never linked to the parent object and remains orphaned.

I was seeing that no matter what I did, the update operation fired when the form was saved did not go through the DMI/operationId I specified.

The form is created with:

public class PhotoForm extends DynamicForm
  public PhotoForm() {
    // init code goes here	
    this.setUpdateOperation("dmitest");	
    this.setAddOperation("dmitest");
    this.setFetchOperation("dmitest");
  }

Here is the DataSource excerpt, where I've redirected fetch/update/add into a dumb do-default DMI.

<DataSource
  ID="medication_photo"
  serverType="sql"
  tableName="medication_photo"
  autoDeriveSchema="true">

  <operationBindings>
     <operationBinding operationType="update" operationId="dmitest">
       <serverObject className="com.test.dmi.TestDMI" methodName="dmitest"/>
     </operationBinding>
     <operationBinding operationType="fetch" operationId="dmitest">
       <serverObject className="com.test.dmi.TestDMI" methodName="dmitest"/>
     </operationBinding>
     <operationBinding operationType="add" operationId="dmitest">
       <serverObject className="com.test.dmi.TestDMI" methodName="dmitest"/>
     </operationBinding> 				
  </operationBindings> 
</DataSource>

Below you can see two fetches (two instances of these DynamicForms) going into the DMI. One of them returns something useful, and I use datasource.getFileURL to load the photo into the Img.

When I click the upload button, it initiates a saveData on the form. However, the update operation does not go through the DMI


You will notice that the component which caused the update to happen is not the original form which created the fetch. In the Watch tab of the Developer Console I see this:


When I've selected the "isc_DynamicForm_20" item, the component that gets highlighted is the FileItem! According to the API, the FileItem is not a subclass of the DynamicForm.

1) What is going on with the extra "isc_DynamicForm_20" being shown as the FileItem?
2) Why isn't the update operation respecting the DMI/setUpdateOperation specified on the DynamicForm?

[Isomorphic]

The extra form is a mechanism we use to isolate the upload field into its own form, so that we can manage the values of other fields on the real form without clearing the upload field. You are seeing this problem because the operations you have specified on your form are not being propagated to the extra "inner" form. We have now corrected this - please try tomorrow's nightly build with your use case and confirm that it is fixed.

Thanks,
Isomorphic Software Support

[sunnyl]

Thanks, confirmed fixed in v8.3p_2013-03-22/PowerEdition Deployment 2013-03-22

[sunnyl]

Spoke too soon!

Is the update operation ID supposed to be changeable during runtime via setUpdateOperation?

While the nightly from 2013-03-22 is now sending my initial save into the DMI to create a temporary child object, when my parent object is saved I would like to be able to make the child object linked to the parent through this process:

1) Temporary photo is uploaded via DMI (works)
2) Parent object is saved (works)
3) DSCallback returns the ID of the parent saved (works)
4) DSCallback calls setUpdateOperation on the photo DymanicForm to run through a different DMI which will use the ID returned in 3 to create the link between the child and the client

Step 4 from above seems to be failing, as the photo's DynamicForm (which I notice now is named properly is the Developer Console - good stuff) update operation still goes the DMI which was used in Step 1 instead of the updated one from Step 4.

Are you able to confirm whether this behaviour is expected?