The other day saw DropDownList get a "working" implementation, but it is not a very "good" or ergonomic one, having to use object types everywhere.
Some possibilities for cleaning this up, in no particular order:
A custom value-type attribute that is interpreted by the IViewFactory for that specific tag; requires adding attribute support to that API and having a way to ignore it for property bindings. Either another attribute type modifier, or using the existing structural token but ignoring it as a structural attribute. This all feels like a hack but it might be the simplest.
A value-type attribute that is implemented as a property on the view, using a wrapper widget type that accepts object types but does all the explicit casting internally. I'm not sure how well this could scale to any number of generic view types, but then again, we only have the one right now and there aren't a ton of others on the horizon, except maybe a radio group.
A wrapper view without an explicit attribute, that creates/recreates an internal generic DropDownList and handles all the casting. This is similar to (2) but would feel, at least to the user, like it "just works" as long as the types are consistent.
(3) is the nicest externally, I think, but it may not be trivially easy to implement some aspects if going with (2) or (3). It's easy to have a non-generic IEnumerable property that can be assigned from any other list, but where things get thorny is with the FormatOption and SelectedOption properties. I don't like the idea of having an implicit value converter that tries to explicitly cast object to some other type because it's going to fail a lot, so what we'd need are some internal "magic" types and converter factories to handle them.
(In other words, the more ergonomic we try to make this on the outside, the messier it's going to look on the inside; same as it ever was.)
The other day saw
DropDownListget a "working" implementation, but it is not a very "good" or ergonomic one, having to useobjecttypes everywhere.Some possibilities for cleaning this up, in no particular order:
A custom
value-typeattribute that is interpreted by theIViewFactoryfor that specific tag; requires adding attribute support to that API and having a way to ignore it for property bindings. Either another attribute type modifier, or using the existing structural token but ignoring it as a structural attribute. This all feels like a hack but it might be the simplest.A
value-typeattribute that is implemented as a property on the view, using a wrapper widget type that acceptsobjecttypes but does all the explicit casting internally. I'm not sure how well this could scale to any number of generic view types, but then again, we only have the one right now and there aren't a ton of others on the horizon, except maybe a radio group.A wrapper view without an explicit attribute, that creates/recreates an internal generic
DropDownListand handles all the casting. This is similar to (2) but would feel, at least to the user, like it "just works" as long as the types are consistent.(3) is the nicest externally, I think, but it may not be trivially easy to implement some aspects if going with (2) or (3). It's easy to have a non-generic
IEnumerableproperty that can be assigned from any other list, but where things get thorny is with theFormatOptionandSelectedOptionproperties. I don't like the idea of having an implicit value converter that tries to explicitly castobjectto some other type because it's going to fail a lot, so what we'd need are some internal "magic" types and converter factories to handle them.(In other words, the more ergonomic we try to make this on the outside, the messier it's going to look on the inside; same as it ever was.)