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

Question about RsFolder parameters #29

Closed
FriedrichWeinmann opened this issue Mar 19, 2017 · 2 comments
Closed

Question about RsFolder parameters #29

FriedrichWeinmann opened this issue Mar 19, 2017 · 2 comments

Comments

@FriedrichWeinmann
Copy link
Member

Hi guys,

I've got a design question:
What was the reason to break with the PowerShell standard for parameters designating paths and introducing the name "RsFolder" for parameters pointing at a folder only?

Cheers,
Fred

@jtarquino
Copy link
Member

We had a long debate with @SQLvariant about it and he consulted with additional MVPs and decided that was the more intuitive name for it as in some places you have the path for the local disk folder and then the RsFolder for those in SSRS, a good example for that case is Write-RsCatalogItem

@FriedrichWeinmann
Copy link
Member Author

Hm ... well, intuitive is a rather subjective thing. I'm one person, you asked many, so odds are you're right on that front (especially considering that I'm not the core audience for this module, coming very much from the PowerShell - rather than the dba - side of things).

However you now have created a naming conflict:

  • When targeting folders versus targeting content elements in RS (such as individual catalog items).
  • You've still got the path/itempath aliases, both for folders as well as content (unless you are willing to commit serious breaking changes)
  • You'll still conflict with the file system parameters (only now it's the aliases conflicting, rather than the main name). Would have gone with 'OutputPath' and 'InputPath' for the FS paths, given how they are the exception, not the rule.

I'll still argue it's the worse approach, even from an intuition perspective, because now people have to relearn habits:

  • Dbas will have to learn that the rest of PowerShell uses 'path' for paths, when they want to apply their PowerShell skills to something other than Reporting Services.
  • PowerShell users that have to pick up Reporting Services have to get used to the other terminology
    (The fact, that aliases exist helps in not breaking existing scripts, however they are a lot worse to discover, so in most cases they won't help with interactive human usage).

Ah well, done is done, but now that I've had my say I can take it with equanimity ;)

Cheers,
Fred

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

No branches or pull requests

2 participants