-
Notifications
You must be signed in to change notification settings - Fork 28
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
Strongly Typed Content Item Converter does not support mapping name from an Option #23
Comments
@aweigold can you give some example of how to reproduce the bug? |
This came from me working with the SDK from our internal app and finding that Options (and Assets for that matter) don't provide a good way to simply map to a string in a strongly typed model. I could see it being useful for someone to just have a field set based on an option being set, without exposing the user to having to use the Option class. For example, if the option is a radio button, it would make sense to just set a String value of that Option's selection. On the Asset side, this would be mapping the URL or description String directly to a field. Given that I don't believe the .Net SDK supports this kind of smart mapping, this may not be a priority, but I wanted to capture the issue as a nice to have. |
You're right, such functionality is not present in the .NET SDK. But let's say you wanted to render radio buttons - wouldn't you use
|
@petrsvihlik I think the usage of Option is fine, and probably could change this from a 'bug' to 'enhancement'. It all goes back to if we want to require a consumer to use our object model. I would beg the question "What's the difference between allowing a StronglyTyped ContentItem versus a StronglyTyped Option or Asset?" In the end, I don't really care that much, we could close this as well. 😄 |
right :) let's change it to enhancement...that should be enough for now :) |
Hi @aweigold , I rephrased the original description so that newcomers understand it. Did I get your point correctly? Thanks! |
Motivation
When rendering a multiple choice elements in a strongly typed model, one must access the
List<Option> value
property of the MultipleChoiceElement class, which might be tedious. There should be a more straightforward path to the names of options.One potential way to handle this would be like the following:
Original description
If an Option is mapped to a field, the name from the option should be used.
The text was updated successfully, but these errors were encountered: