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

Validation approaches in Descriptor #50

Open
KathleenDollard opened this issue May 30, 2020 · 1 comment
Open

Validation approaches in Descriptor #50

KathleenDollard opened this issue May 30, 2020 · 1 comment

Comments

@KathleenDollard
Copy link
Owner

Some of the kinds of CLI creation for validation is predictable:

[Range(7, 150)]
public int MyValue { get; set; }

Which could be handled by an IValidation that produced the right validation. But more complex stuff, like the folks requesting FileInfo relative to another directory might be better served by a construct that combined type with validation. This would ensure validation was aligned with the argument type. Something like

// Derive classes that contain the situation specific data needed for the CommandMaker step
public class WrappedArgumentType
{
   public Type Type {get; set; }
   
}
@KathleenDollard KathleenDollard moved this from To do to Hold: First issue, discussion or blocked in Complete Initial Development May 30, 2020
@KathleenDollard
Copy link
Owner Author

KathleenDollard commented Jun 1, 2020

There is a more important reason to wrap the argument type.

The Type type is actually a reflection type, although it resides in System (as does Attribute). Information on a type will be different in source generation, and a JSON CLI definition (resulting in dictionary or dynamic results) would be different again.

This is seen in the fact the ArgumentType is retrieved in the Specific layer, not the General layer. However, the type returned is a Reflection type - that's not going to work. See #56

This also allows more validation/tab completion to be driven by the type allowing that to be an internal choice - although it isn't yet evident where that choice resides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Complete Initial Development
  
Hold: First issue, discussion or blocked
Development

No branches or pull requests

1 participant