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

Naming convention for site collection commands #105

Closed
waldekmastykarz opened this issue Dec 8, 2017 · 7 comments
Closed

Naming convention for site collection commands #105

waldekmastykarz opened this issue Dec 8, 2017 · 7 comments
Labels

Comments

@waldekmastykarz
Copy link
Member

What do you think would be the logical naming convention for working with site collections in the CLI?

Today, we have classic and modern sites. While they're both site collections, you work with them differently (different API, parameters and shape). In PnP PowerShell there are two sets of cmdlets: PnPTenantSite for classic sites and PnPSite for modern sites. What would be the logical naming convention to use in the CLI?

  1. spo site <action> for modern and spo site classic <action> for classic sites (since modern sites are likely the way forward it would be better to not include modern in the command name, and instead explicitly denote classic sites)
  2. spo modernsite <action> and spo classicsite <action>
  3. spo site modern <action> and spo site classic <action> to explicitly denote type of site you want to be working with
  4. spo site <action> --type Modern|Classic for both classic and modern. Distinction between classic in modern is done inside each command. This would introduce higher complexity of all commands because they would have to handle two types of sites, including validating required options which are different depending on the type of site you're working with. Preferably we shouldn't choose this approach but maybe you have good arguments for doing it.

Any other naming conventions? Which one has your preference and why?
@VelinGeorgiev @estruyf @andrewconnell @wictorwilen

@VelinGeorgiev
Copy link
Contributor

Option 1 : spo site <action> for modern and spo site classic <action> for classic sites.

@benstegink
Copy link

I vote for #1 as well

@andrewconnell
Copy link
Contributor

Option 4 makes most sense to me with —type Modern being the default.

Why? Most CLI commands only have non-parameterized arguments as details on the command. To me, the type of a site is a switch, not details on the command, so it doesn’t make sense to put it as one of the arguments like option 1.

With that being said, I could live with option 1.

@waldekmastykarz
Copy link
Member Author

@andrewconnell just to double check if we're talking about the same:

In 1) commands would look as follows:

spo site add --title <title> --description [description] ...
spo site list
spo site classic add --title <title> --description [description] ...
spo site classic list

The only command that accepts a non-parametrized argument is spo connect <url>. I realize it might have been confusing of me denoting the command verb as <action> in the examples in the initial question. My bad.

@andrewconnell
Copy link
Contributor

Correct... I think to go in line with what most CLIs do I'd expect to see something more like option 4:

spo site list --type classic
spo site list --type modern
# the following is the same as the modern option above
spo site list

@waldekmastykarz
Copy link
Member Author

I like the simplicity, but I'm concerned with the implementation and maintenance complexity it brings. We'd need to wrap the whole body of validation and command action in a big if..then..else block because the implementation for either type of site is 100% different. What's also confusing for example are the expected values for parameters like WebTemplate: where for classic site you would specify for example STS#0 to get all team sites, but for modern sites you'd specify 64 to get modern team sites.

@waldekmastykarz
Copy link
Member Author

I took a closer look at the APIs that we have to use to work with sites in SharePoint and it seems there are too many differences between managing classic and modern sites. Both types of sites have different parameters and in some cases the same parameters even have different allowed values. Supporting both types of sites in one command would be challenging but explaining how the commands work in the help and which arguments are required when would be even harder. With that, let's go with 1) for now. If anything changes in SharePoint and its APIs we can always revise and merge support for both sites in one command.

Thanks for your opinions everyone, much appreciated! 👍

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

No branches or pull requests

4 participants