HTML client view not refreshed after performing action

[ChrisSmith2]

When viewing one of my custom objects (e.g. on its Summary view), the client does not receive a refresh event after an action is performed (using the "Actions" drop-down menu). Is this a known issue, or something not covered in the "chassis-b" sample? Is there a way to ensure that the client is updated?

I really hope this is a bug (or an error in my plugin) rather than by design. This issue means that stale information is always left in the main UI after performing an action, which is a really poor user experience. I hope I've missed something here - otherwise, it seems the "Actions" drop-down is basically unusable for HTML plugins.

I have used the setGlobalRefreshHandler() call to register the refresh callback, and it is called correctly when manually clicking on the Refresh button in the VMWare toolbar.

I have set the action handler in the service Java code to call actionResult.setObjectChangedResult(), and I can see the VMWare-controlled fields (on the navigation pane, and in the title of my summary page to the left of the "Actions" drop-down menu) update when the action completes.

Even the Refresh icon in the VMWare toolbar turns into the spinning busy icon as the action occurs, before returning to its static image - but my refreshData() function is never executed unless the user manually clicks the Refresh button.

Any suggestions/solutions much appreciated!

[laurentsd]

Deploy the ChassisA sample locally and see its summary page and the code at chassis-summary.js: if you change the chassis name with the Edit action  the summary page is refreshed with the new name.  Try to see what is different between your code and that sample, it should work.  Also, what exact version of vSphere HTML client are you using?

[ChrisSmith2]

The "chassis-a" sample built without any modifications from the 6.5.0 SDK fails in the same way - see attached screenshot. I've repro'd this behaviour with the "chassis-a" sample on both the 6.5.0 SDK client (6.5.0 build 4598948) and on the latest production VSphere Server 6.5.0d (6.5.0.5300). The same result occurs on both versions using either Edge (40.15063.0.0) or Chrome (58.0.3029.110 64-bit).

Repro steps used for the screenshot:

1) Build the "chassis-a" sample (source and built packages attached).

2) Install by copying the JAR and then the WAR to the "pickup" folder.

3) Go to Menu, Global Inventory Lists, and select "ChassisA".

4) Select "Chassis 2" on the left-hand navigation pane to show its summary page.

5) Click the "Actions" drop-down next to "Chassis 2" in the header, "Edit chassis".

6) Add "XXXX" to the end of the chassis name, then click Submit.

7) The VMWare-controlled elements (title and left-hand navigation pane) change to "Chassis 2XXXX" (highlighted in green in the screenshot).

😎 The plugin-controlled elements in the page content (accordion header and bullet points) remain "Chassis 2" (highlighted in red in the screenshot).

[laurentsd · Accepted solution]

I got more details from other people in our team on that topic. The bottom line is that our current design for refreshing a plugin view automatically after a user action is not good, for instance we have found that triggering a global refresh event can lead to other errors. Unfortunately this can only be fixed with newer APIs which are on our backlog.  For now my only recommended solution is to add a "Refresh" button in your plugin view to indicate to the user that the current data may be stale.

[ChrisSmith2]

Thanks for the response. Whilst this is disappointing news, at least I know not to spend more time trying to diagnose or work around this behaviour in our plugin. We'll treat this as a known issue for now, and try to redesign our UX to reduce end-user confusion at some point in the future.

[jvitorino]

Hi,

It's been a while since this was answered and we just ran into the same situation on 6.5 and 6.7.  I was wondering if there has been any changes in the latest releases that will allow us to refresh a summary view if the object is modified as described in the OP?  You mentioned that this was in the backlog, would you be able to let us know if it's low/high in the backlog?

Thank you,

Jesse

[Denis_Chorbadzh]

Hi Jesse,

Unfortunately, this is still not possible if you are using the custom objects extensibility.

We have already introduced the new JS APIs in 6.7 and 6.5U2 which give you the possibility to pass/get information to/from modal dialogs, which effectively means that you will be able to refresh your views. We have provided a new HTML sample in 6.7 and 6.5U2 SDKs which demonstrates this.

Best Regards,

Denis

[ChrisSmith2]

Denis - unfortunately the new APIs don't solve the core issue - updating the UI when an asynchronous state change completes. A mechanism for this is clearly implemented for VMWare-owned objects, even where huge numbers may exist (e.g. VMs that start/stop immediately have their icons and status text updated in detailed views, the navigation pane, and lists), but no equivalent is available for third-party vendors.

As far as I can tell, the only way the new APIs would help is to keep the modal dialog open until the operation completes - but because it is modal, this makes the entire UI unusable for potentially minutes for long operations.

[Denis_Chorbadzh]

Hi Chris,

You do not need to keep the modal dialog open while waiting for the operation to complete.

Instead of triggering the task from the modal dialog, you can do your configuration/setup in the modal dialog, send the object back to the view and trigger the task from there.

For example:

- create an onClosed handler which triggers a task when the dialog is closed (using the information passed from the dialog)

- open a modal dialog

- make your configuration and pass the object to the close() function

- your onClosed handler will be called with the configuration object and you can trigger an async taks

Hope this helps,

Denis

[_vladi_]

Hi folks,

I agree with all of the above but in different ways. 🙂

You can do partial workarounds like the ones Laurent and Denis suggest but essentially support for status update and refresh of long-running operations is still NOT implemented.

Despite the interest there is a reason for this: it requires architecturally significant changes to the vCenter itself and relevant APIs, not just changes on the vSphere Client side.

Such behavior is in the works but the scope is major so I can't comment on timelines for this, neither whether it would be supported for local or remote plugins.

@Chris: The live refresh in the Client you mentioned is available only for certain managed objects and their most important workflows. For the aforementioned reasons a general live refresh solution is not present neither for the core features nor for plugins.

Let's see how this story develops down the road as this is a common plugin use case we are all interested in.

Cheers,

Vladi

[ChrisSmith2]

Thanks Vladi!

We'll continue to monitor this and hope that a viable solution to overcome this major functionality gap becomes available in the future.