PscxPathCommandBase ideas

Topics: Developer Forum, Project Management Forum
Apr 4, 2007 at 8:15 PM
Edited Apr 4, 2007 at 8:50 PM
I was thinking about creating a new attribute for constraining derived cmdlets to one or more providers, e.g. here's a contrived example:

[Cmdlet(VerbsCommon.Get, "Extension")]
public class GetExtensionCommand : PscxPathCommandBase { ...

Our PscxPathCommandBase cmdlet would ensure that the -Path or -LiteralPath was constrained to the chosen provider(s) before passing the PathInfo to ProcessPath(). The lack of a ProviderContraintAttribute would mean pass all PathInfos. Multiple ProviderConstraint attributes can be applied to the cmdlet class.

The same attribute might be placed on arbitrary output path parameters also, and be automatically checked by the base class.

Apr 8, 2007 at 12:54 PM
Good idea, however multiple providers could return the same type of object so maybe the constraint should be applied to the object returned by provider.

An example would be a filesystemprovider that returns enriched FileSystem objects.

I've just started on my first provider, and i must confess i don't know of any way to query the provider for the type of object returned without actually retrieving it.
Apr 8, 2007 at 2:43 PM
The constraint was originally conceived for constraining parameter directed paths for input and output. Any objects -- regardless whether they came from a provider or not -- can be brought in from the pipeline and these are dealt with via RegisterInputObject<T> in the PscxCmdlet base. Also, any objects can be written out to the pipeline. Like the subject mentions, this is for Path related functionality only. Perhaps the attribute would be better named "ProviderPathConstraint"