Provides object implementation of the ContainerView object and methods.

[jrmycanady]

This is a similar "wrapper" to ListView but for ContainerView.

[vmwclabot]

@jrmycanady, you must sign our contributor license agreement before your changes are merged. Click here to sign the agreement. If you are a VMware employee, read this for further instruction.

[punalpatel]

Following error seen in travis-ci

$ make check test
checking go imports...
diff -u view/manager.go.orig view/manager.go
--- view/manager.go.orig 2017-02-19 17:29:30.164895825 +0000
+++ view/manager.go 2017-02-19 17:29:30.164895825 +0000
@@ -64,6 +64,6 @@
if err != nil {
return nil, err
}

• return NewContainerView(m.Client(), res.Returnval), nil
  }
  make: *** [goimports] Error 1
  The command "make check test" exited with 2.

[jrmycanady]

The issue has been corrected.

[dougm]

Thanks @jrmycanady , looks good. I don't think we need both object.ContainerView and view.ContainerView though, just view.ContainerView.

Not sure why we did this for ListView, but PR #669 removes object.ListView. @cgtexmex ?

[jrmycanady]

@dougm, I've updated the pull request and removed object.ContainerView.

I was also confused why there were both types. My only thought was that there was a desire to have every managed object defined under the object package. But if that is the case, I would think we would only need the object.ContainerView/object.ListView and could dump the view.ContainerView/view.Listview.

I suppose on that topic, are there any layout/design guidelines on where things should be located? For example, why is the ViewManager special and located in it's own package while the StorageResourceManager is located in the object package?

[dougm]

@jrmycanady we don't have any layout guidelines written down, though it would be worth doing so. The short story is we don't want everything in the object package. There was a re-org in PR #231 where a number of the manager types moved to their own packages. However, some were stuck in the object package to avoid cyclic imports. And others have probably just slipped in without considering how they might fit well in their own package. I'd also like to have some of the generated types/methods split into their own packages, but that's another story. In the case of this PR, it fits well in the view package. We can take another look at splitting out some of the object types at some point.

[vmwclabot]

@jrmycanady, VMware has approved your signed contributor license agreement.