You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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; }
}
The text was updated successfully, but these errors were encountered:
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.
Some of the kinds of CLI creation for validation is predictable:
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
The text was updated successfully, but these errors were encountered: