-
Notifications
You must be signed in to change notification settings - Fork 30
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
Add V2 workspace tree view #388
Conversation
readonly application: { | ||
readonly branches?: { type: string }[]; | ||
readonly resources?: { type: string }[]; | ||
} | ||
readonly workspace: { | ||
readonly branches?: { type: string }[]; | ||
readonly resources?: { type: string }[]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For application branches and resources, I think type should be an AzExtResourceType
.
For workspace branches and resources, it can be an arbitrary string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree necessarily, but I think I'd like to address this as a follow up PR so as to not get mixed up with all the rest, and give me time to think about this.
Adds a basic implementation of the V2 workspace tree view. This is mostly a refactoring of the application (i.e. resources) tree view into common base types that work across both. Despite the number of files changed (mostly due to naming), most of the logic is the same as used by the application tree view, just made more generic.
Notable changes (and open for discussion):
We need an expanded "contribution registration" mechanism to accommodate both application and workspace resource providers. Here's what I propose (by way of an example
package.json
):application
andworkspace
sections, with each having resource provider (i.e.resources
) and brand data provider (i.e.branches
) sections. Providers are specified using an object that contains (today) just atype
property (but could be expanded in the future, such as to help differentiate kinds, etc.).