Closed OskarKlintrot closed 7 years ago
Maybe it makes more sense if EnumFieldAttribute
can distinguish between field.Keywords
and field.Value
depending on which one is .Any()
?
The only reason I would consider this potentially wrong is because you wouldn't want to have to recompile your code each time you extend a Category of Keywords. If Keywords were immutable then it would seem an excellent fit.
In many use cases it would be a much better to use a property of a Keyword (or its Metadata) in such a way that it can be extensible without compilation.
For example: Using keywords to manage the col-spans in a front end grid system could use the Keyword Value "1/3 Width" with a Key "col-md-4" etc.
However, there are likely to be use cases which I have not considered so provided this is implemented in such a way that it is available without replacing de-serializing Keyword values as a type it may be a nice addition.
I would also suggest having the option to decorate your enum values with attributes to explicitly match the Keyword as an optional alternative to convention based mapping. This could even use the DescriptionAttribute as demonstrated here: http://blog.spontaneouspublicity.com/associating-strings-with-enums-in-c
Although Vouzamo has a good point about the mutability of keywords, it is the implementor's choice whether or not they want to model the keywords as an enum. You don't have to use the EnumField annotation if you don't want to.
I don't know if this can be interesting to add to DD4T but why not allow Keywords to be parsed to enums as well? To me it makes sense, but I don't know what you think. I just created an example implementation, I can't run it though so I don't know if it works, I just wanted to show you what probably could look like.
bool EnumTryParse(Type enumType, object value, out object parsedEnum)
is reused fromEnumFieldAttribute
, which is not very DRY.