Vscode-extension-for-zowe: Code restructure - Use Interfaces and Abstract Classes

[Colin-Stone]

Legacy debt. Zowe Explorer originates from three separate plugins and although a lot of effort has gone in to making all three behave the same there are some areas of inconsistency which need to be ironed out.

To do this I propose creating AbstractZoweNode and AbstractZoweProvider representing nodes and trees respectively and allowing the three sets of classes to converge areas of common function and behavor and rationalize testing.

[jellypuno]

@Colin-Stone Can you share with me the architectural approach on how you are going to do this? I want to keep this in mind as I think about issue #354

[Colin-Stone]

@Colin-Stone Can you share with me the architectural approach on how you are going to do this? I want to keep this in mind as I think about issue #354
I have rewritten this based upon what I have learned

1. Use interfaces rather than classes. We now have IZoweTree and IZoweTreeNode. I would like to use these in preference to concrete classes and expand them as necessary.
2. Separate out server call logic into the actions files
3. There are two classes we currently either inherit or extend. TreeItem class and TreeItemProvider interface. Each container has extending classes for these. Methods such as getTreeItem and getParent are implemented in the three provider classes and could be pushed to an intermediate abstract class and getChildren may be something we can extract the common function from and put into the intermediate class. ZoweAbstractProvider
   I don't yet have a definitive list of the methods we would restructure yet but my first pass would be to list the common methods and what function could be moved out.
4. I want to look standardizing the way TreeItems are built as the number of parameters on a new call has grown. I think we can do this better and in line with updating of the label handling come up with a solution that applies to each object type. I think an AbstractZoweNode would address this.

[jellypuno]

ok. I see. cool! thank you.

Is this the same as this one? #75

[Colin-Stone]

75 is changing the three containers into one container. In other words just one tree. That was my original intention to bring everything together. The profile object would still be the root object but you would then have a node that indicated the type and filter. E.g. Datasets "MYHLQ". Some people think it's a nicer way to do it, others don't. But I have never had an opportunity to implement it. Ideally I would have it as a setting you could either have the three containers or the one

[Colin-Stone]

This is how I have done this.

1. Create specific Interfaces
   interface IZoweTree<T> extends vscode.TreeDataProvider<T>
interface IZoweTreeNode
interface IZoweDatasetTreeNode extends IZoweTreeNode
interface IZoweUSSTreeNode extends IZoweTreeNode
interface IZoweJobTreeNode extends IZoweTreeNode
2. Add to these the fields and methods that cross class boundaries
3. Push common fields and methods to super class where possible
4. Change Implementing classes to use interfaces in methods

Nodes can now be referenced via interfaces only. Not yet 100% the case with Trees, within extension they may still need to be referenced by concrete class

Next steps:
Review the current interfaces IZoweTreeNode.ts and IZoweTree.ts files considering

1. Change all parameter references in class methods to use interface including test cases
2. Refactor extension.ts so that commands/functions now reside in correct interface/class
3. Refactor with the intention of reducing interface fields/functions that were convenience. As for the point above. In other words try and reduce external interfaces

Still to do

1. Move test cases from original implementation file to most appropriate one
2. Should we consider an architecture that locks down based on commands rather than interfaces?

[Colin-Stone]

Created the following type
export type IZoweNodeType = IZoweDatasetTreeNode | IZoweUSSTreeNode | IZoweJobTreeNode;

meaning we can now specify the following generic interfaces as operations on IZoweTree

rename(node: IZoweNodeType);
open(node: IZoweNodeType, preview: boolean);
copy(node: IZoweNodeType);
paste(node: IZoweNodeType);
delete(node: IZoweNodeType);
setItem(treeView: vscode.TreeView, node: IZoweNodeType);
saveSearch(node: IZoweNodeType);
saveFile(document: vscode.TextDocument);
refreshPS(node: IZoweNodeType);
addHistory(element: string);
getHistory();
deleteSession(node: IZoweNodeType): any;
getTreeView(): vscode.TreeView;
filterPrompt(node: IZoweNodeType): any;

so for example: filterPrompt replaces datasetFilterPrompt, ussFilterPrompt and searchPrompt.

This would then require a large operation of moving function out of extension.ts to the tree along with all the associated unit tests.

[Colin-Stone]

This part of the Epic has been done.