Add support for multiple options in action fields.

[kevinswiber]

Design a way to provide a list of options.

Something like...

{
  fields: [
    { name: "color", type: "radio", value: "blue", 
      options: [{ name: "Blue", value: "blue" }, { name: "White", value: "white" }] }
  ]
}

[eserating-chwy]

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.
The other thing I would suggest is adding an indicator for the default selected option, e.g. [{ name: "Blue", value: "blue", default: true}]

[justinoverton]

Is this going to be put into the spec?

[kevinswiber]

There is similar ongoing discussion here: https://groups.google.com/forum/#!topic/siren-hypermedia/xDqxQ4gMgYk

[ericelliott]

I like the single field, multiple options approach. type: "radio" or type: "checkbox" is also fine, but I would prefer type: "select" with a multiple attribute, as described in the HTML spec.

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.

[gxxcastillo]

@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

[ericelliott]

Yeah, maybe it's better not to deviate too much from the HTML spec...

[ryanhiebert]

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 select with options, but then we'd also need to have a select-many or something similar to also give us the semantics we look for with checkbox. Perhaps it's just not worth it to deviate from HTML for this purpose.

[ryanhiebert]

I just implemented a toy api using the HTML-based duplication of fields using radio, and I'm back wanting a select type, with an options additional key. the duplication of type and just bugs me.

I like select and multiselect for the names. I also like the general idea of the options array of objects, but I wonder if using title instead of name as the human-readable form of value would be more consistent with other places in the spec.

[ericelliott]

Maybe this is a good place to deviate from HTML a little. An input type, select, with an optional multiple attribute and a list of options (option) would be ideal, I think. Something like:

{
  "fields":  [
    {
      name: "color", type: "select", 
      options: [
        {
          name: "Blue", value: "blue", selected: true
        },
        {
          name: "White", value: "white"
        }
      ]
    }
  ]
}

[ericelliott]

Maybe change name to title.

[paulwalker]

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.

{
  "fields":  [
    {
      name: "color", type: "select", value: "blue",
      options: [
        {
          name: "Blue", value: "blue"
        },
        {
          name: "White", value: "white"
        }
      ]
    }
  ]
}

Maybe that could also allow for simply using key/value pairs instead of an array of objects?

{
  "fields":  [
    {
      name: "color", type: "select", value: "blue",
      options: { blue: "Blue", white: "White" }
    }
  ]
}

[paulwalker]

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?

{
  "class": [
    "order"
  ],
  "properties": {
    "orderNumber": 42,
    "itemCount": 3,
    "status": "pending"
  },
  "entities": [
    {
      "class": [
        "items",
        "collection"
      ],
      "rel": [
        "http://x.io/rels/order-items"
      ],
      "href": "http://api.x.io/orders/42/items"
    },
    {
      "class": [
        "info",
        "customer"
      ],
      "rel": [
        "http://x.io/rels/customer"
      ],
      "properties": {
        "customerId": "pj123",
        "name": "Peter Joseph"
      },
      "links": [
        {
          "rel": [
            "self"
          ],
          "href": "http://api.x.io/customers/pj123"
        }
      ]
    }
  ],
  "actions": [
    {
      "name": "add-item",
      "title": "Add Item",
      "method": "POST",
      "href": "http://api.x.io/orders/42/items",
      "type": "application/x-www-form-urlencoded",
      "fields": [
        {
          "name": "orderNumber",
          "type": "hidden",
          "value": "42"
        },
        {
          "name": "productCode",
          "type": "select",
          "reference": { "type": "link", "rel": "products" },
          "property": "code"
        },
        {
          "name": "quantity",
          "type": "number"
        }
      ]
    }
  ],
  "links": [
    {
      "rel": [
        "self"
      ],
      "href": "http://api.x.io/orders/42"
    },
    {
      "rel": [
        "previous"
      ],
      "href": "http://api.x.io/orders/41"
    },
    {
      "rel": [
        "next"
      ],
      "href": "http://api.x.io/orders/43"
    },
    {
      "rel": [
        "products"
      ],
      "href": "http://api.x.io/products"
    }
  ]
}

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.

[paulwalker]

My latest iteration on this is to simply include one "reference" field with the relevant data.

"reference": {
    "type": "link",
    "rel": "products",
    "value": "id",
    "name": "name"
}

[Kampfgnom]

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.