shankarvn
Contributor
Contributor

Auto-refresh behavior of views in the web client

Hi,

I was wondering if somebody could help me understand the default out-of-the-box behavior of views auto-refreshing themselves in the web client framework. The only information that I could find on this was the following page in the documentation which appears to be saying that views are never refreshed due to changes done through other clients and a manual refresh is always required.

vSphere 5.5 Documentation Center

However, I find that the views are indeed getting refreshed every 10 minutes or so and as a side effect of that, views are picking up changes that are made through other clients. Any insight into how the view refresh is supposed to work would be helpful.

Thank you.

Tags (1)
13 Replies
rdey
Enthusiast
Enthusiast

The documentation is correct.

What is the build number you are using? If you are using one of the beta versions ( I think it was beta1), there was a bug where auto refresh was enabled every 10 minutes to fix another bug. But that has been fixed in 5.5 GA, so if you use 5.5 GA version you should not see this behavior.

shankarvn
Contributor
Contributor

Hi rdey,

Thank you for your response. Given that we have our own refresh counters for our plugin, I was wondering how we can programmatically invoke a "view refresh" as if someone clicked on the refresh icon. I tried doing the following

dispatchEvent(new DataRefreshInvocationEvent(DataRefreshInvocationEvent.EVENT_ID));

However, the above works only when invoked from some places (for example: action commands declared in the plugin.xml that invoke the above line by dispatching the event always refreshes the view). If I have my own class (not a part of the plugin.xml) that does the above, I do not see the view getting refreshed. Can you give me a reliable way to trigger a refresh programmatically?

Thank you very much.

0 Kudos
rdey
Enthusiast
Enthusiast

When a user clicks on the global refresh button DataRefreshInvocationEvent is generated by the framework. So in your code you should capture this event and request data from the backend to refresh your UI.

See the ChassisSummaryViewMediator class in chassis-ui sample for how it is done.

0 Kudos
shankarvn
Contributor
Contributor

Hi rdey,

Thank you once again for your response. We do not like the "No auto refresh" behavior and waiting for the user to click on the "Global refresh button" to trigger a refresh. For our plugin, we have a mechanism to know when to go fetch data from our server through the java service layer. What I want is to programmatically trigger the global refresh based on our conditions for triggering a refresh if that is possible. Please let me know if that is possible and if "dispatchEvent(new DataRefreshInvocationEvent(DataRefreshInvocationEvent.EVENT_ID))" is the way to do it

Thank you.

0 Kudos
shankarvn
Contributor
Contributor

Hi

Could anyone please help me understand when the following line of code will trigger a "full refresh" - dispatchEvent(new DataRefreshInvocationEvent(DataRefreshInvocationEvent.EVENT_ID))


Thank you.


0 Kudos
laurentsd
VMware Employee
VMware Employee

DataRefreshInvocationEvent is just an event being sent on the event bus, so only views which are reacting to that event perform their own refresh.


    [EventHandler(name="{com.vmware.core.events.DataRefreshInvocationEvent.EVENT_ID}")]

   public function onGlobalRefreshRequest(event:DataRefreshInvocationEvent):void {

      requestData();

   }

0 Kudos
shankarvn
Contributor
Contributor

Hi laurentsd,

Thanks for the response. I see the following sample code (and my question is along these lines)

////////////////////////////////////////////////////////////////////////////

private function refreshUi(context:ChassisActionContext):void {

      if (context.reference != null) {

         // Send a ModelChangeEvent with the modified object to update the UI

         dispatchEvent(

            ModelChangeEvent.newSingleObjectChangeEvent(context.reference, context.opType));

      } else {

         // Use a global refresh event when we don't know the modified object,

         // in case a new chassis with the same name already exists.

         dispatchEvent(new DataRefreshInvocationEvent(DataRefreshInvocationEvent.EVENT_ID));

      }

   }

////////////////////////////////////////////////////////////////////////////

The above code runs in response to edit/delete chassis action and works very nicely in the context of "actions". However, if I initiate this using a timer from a class outside of these actions, then calling the following code => "dispatchEvent(new DataRefreshInvocationEvent(DataRefreshInvocationEvent.EVENT_ID));" does not refresh the same chassis table view. For example, from the main plugin entry point, if you create a timer that does a repeated refresh call like above, that does not do anything to the chassis view while you are sitting and watching the table view. Imagine that in the chassis example, a separate java thread keeps changing the chassis info periodically and we want the table view to reflect the new information in the table columns by asking the ObjectStore (by calling getAllChassis()) periodically; this is as opposed to the user coming and clicking the refresh button which under the covers goes through the ChassisAdaptor and makes a call to getAllChassis() - How would we do this?

Thank you.

0 Kudos
shankarvn
Contributor
Contributor

Hi laurentsd,

Any pointers on this?

Thank you

Shankar

0 Kudos
laurentsd
VMware Employee
VMware Employee

One thing to understand is that the Web Client doesn't have any Auto Refresh mechanism by design.  If you open a vSphere object view or object list (host, vm, etc.) and stare at it for hours, nothing will change.  This is done on purpose so that the client doesn't burden the back-end with constant refresh requests, it doesn't scale up.  When you navigate to a new view the information is refreshed by the view mediator and this is good enough in most cases.   If you need a particular view to do display some live update you can add a timer in that view's mediator that pulls data every few seconds, but it should be active only while the view is open (i.e. stop the timer as soon as the context is reset to null).

It is bad practice to run a timer in the background like you are doing from your plugin entry point.

You are not supposed to run any client side code outside your own view mediators or action handlers. 

0 Kudos
shankarvn
Contributor
Contributor

Unfortunately, the global table views (like for example from the sample: the chassis table view) do not have a context object but these views in our plugin can change when certain background operations are performed (For example: another client operating on our custom object). Although I understand the general philosophy of not running client code outside of view mediators and action handlers and your design, I am not clear on where this view i.e. table views fit in; they do not have view mediators. All I can see with these views is request for properties being made from the DataAdapter layer in an opaque manner. The issue for us is leaving the views stale can result in subsequent erroneous operations that can put our user in doubt as to what is going on with the system. So my question is when a user clicks on the Chassis view which displays all the chassis objects, what is the "view" and how can this view refresh periodically (there is no context object here)?

Can you tell me what handler does clicking on the refresh button call?

Thank you.

0 Kudos
laurentsd
VMware Employee
VMware Employee

The standard objects list view is handled by the Web client, it cannot be customized.

There is no reason for you to update this list dynamically, it doesn't happen in rest of the Web client either, so it is consistent.

Users won't be confused as long as you handle their action correctly:  when an action is selected for an object you call your back-end to verify the state of the object and if the action is not applicable anymore you let the user know that something has changed when the action returns to the client. At the same time you can send a ModelChangeEvent to refresh the list.

naveen_askquest
Enthusiast
Enthusiast

hi laurent,

I also have similar problem.

could i conclude above thread discussion as:-

Global refresh button click event can not be triggered from plugin mediator class.?

0 Kudos
laurentsd
VMware Employee
VMware Employee

What I explained earlier in this thread  is that there is no need to issue a global refresh from a plugin mediator class.

0 Kudos