-
Notifications
You must be signed in to change notification settings - Fork 71
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
Add support for multiple options in action fields. #3
Comments
I would say that should be able to have "options" where you define the options inline, but maybe also have something like "optionsURI" where it points to somewhere that will return a list of options. |
Is this going to be put into the spec? |
There is similar ongoing discussion here: https://groups.google.com/forum/#!topic/siren-hypermedia/xDqxQ4gMgYk |
I like the single field, multiple options approach. Radio and Checkbox are UX concerns which, IMO are better left to a stylesheet. I suspect they got into HTML because they were introduced long before CSS, but if they had been proposed later, they would have beed handled by CSS, instead. |
@dilvie, I think I confused things in that thread by comparing to "select" as there is no "select" type, but rather a "select" element. Currently, Siren only supports input types |
Yeah, maybe it's better not to deviate too much from the HTML spec... |
The HTML spec way to do this would be to have multiple fields with the same name. I think I like the idea of a |
I just implemented a toy api using the HTML-based duplication of fields using I like |
Maybe this is a good place to deviate from HTML a little. An input type, {
"fields": [
{
name: "color", type: "select",
options: [
{
name: "Blue", value: "blue", selected: true
},
{
name: "White", value: "white"
}
]
}
]
} |
Maybe change |
Out of curiosity, why the use of a "selected" field rather than simply using a "value" top level field as is used with other types.
Maybe that could also allow for simply using key/value pairs instead of an array of objects?
|
As mentioned by Gabriel Castillo in the other thread, I would also like to explore the semantics for referencing an entity or link as the source of available values for a particular field. This seems like a common scenario in which a value has to be selected for a foreign key field. Has anyone dealt with this in their siren representations? We can even use the "add-item" action as an example from the main example on this project. One of the fields is a "productCode." Where are the list of codes supposed to be derived from? How about something like this?
You can see I have added a link for "products" and the productCode field has been changed to a select. The "reference" field contains the meta information to inform the client where to obtain the list of values and the "property" field informs the client what property to use from the individually selected item. I wonder if there should also be another field to indicate what property to be used for the name/title. |
My latest iteration on this is to simply include one "reference" field with the relevant data.
|
What is the status in this issue? Is there some agenda on when to include this into the standard? I actually like the solution provided by @paulwalker above: {
fields: [
{
name: "color", type: "select", value: "blue",
options: [
{
name: "Blue", value: "blue"
},
{
name: "White", value: "white"
}
]
}
]
} I would refrain from simply using key/value pairs, since you never know what you're adding in the future. |
Design a way to provide a list of options.
Something like...
The text was updated successfully, but these errors were encountered: