Move PscxInputObjectPathCommand functionality to PscxCmdlet

Topics: Developer Forum
Feb 14, 2007 at 7:24 PM
What do you think about moving the core InputObject functionality into PscxCmdlet? There would be the following classes:

PscxCmdlet would contain the RegisterInputType<T> stuff and ProcessInputObject
PscxInputCommandBase would add the InputObject property and would call the PscxCmdlet.ProcessInputObject
PscxPathCommandBase would by practically the same as now
and PscxPathInputCommandBase would be like the PscxInputCommandBase, only derived from PathCommandBase.

Some of the window management commands from Jaykul would be perfect candidates for the PscxInputCommandBase..
Feb 15, 2007 at 4:53 PM
As long as it doesn't involve major refactoring work for derived cmdlets, I think that's a logical step. The very core essence of any cmdlet is accepting input objects; no better place than the root object.
Feb 15, 2007 at 6:00 PM
No, it's not going to be a major refactoring, only the base classes would change.

However I plan another refactoring, which would affect some of the derived classes. Today, there are these usage patterns:

- file only processing, wants either paths or FileInfos
- file & dir processing, wants either paths or FileSystemInfos

The new InputSettings would reflect these patterns. You'd be able to set these properties

PathInputSettings.FileSystemBehavior = PathInputMode.ProcessAsPath; // all file system input objects converted to a path string 
PathInputSettings.DirectoryBehavior = PathInputMode.Ignore; // directories, be it a path or an object, are ignored
PathInputSettings.FileBehavior = PathInputMode.ProcessAsObject // files, got either by path or as object, are processed as FileInfos

what do you think? would it simplify some of the commands? i need to think about it a bit more, it's in a no way a finished idea :)