Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provides object implementation of the ContainerView object and methods. #667

Merged
merged 1 commit into from
Feb 21, 2017
Merged

Provides object implementation of the ContainerView object and methods. #667

merged 1 commit into from
Feb 21, 2017

Conversation

jrmycanady
Copy link
Contributor

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

@vmwclabot
Copy link
Member

@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
Copy link

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
Copy link
Contributor Author

The issue has been corrected.

Copy link
Member

@dougm dougm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@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
Copy link
Member

dougm commented Feb 21, 2017

@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.

@dougm dougm merged commit 4994038 into vmware:master Feb 21, 2017
@vmwclabot
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants