conditional fields in actions

[paulwalker]

Another common use case that is not currently covered is the necessity of fields based upon the inputted/selected value from another field. Just to get the discussion going on this, this is how I am currently handling this:

"actions": [
    {
      "name": "create",
      "method": "POST",
      "href": "/a/ranks/1/qualifications",
      "type": "application/json",
      "fields": [
        {
          "name": "path",
          "type": "text",
          "value": "default"
        },
        {
          "name": "type",
          "type": "select",
          "options": {
            "certification": "Certification",
            "sales": "Personal Sales",
            "group_sales": "Group Sales"
          },
          "value": "sales"
        },
        {
          "name": "name",
          "type": "text",
          "visibility": {
            "control": "type",
            "values": [
              "certification"
            ]
          }
        },
        {
          "name": "product_id",
          "type": "select",
          "visibility": {
            "control": "type",
            "values": [
              "sales",
              "group_sales"
            ]
          },
          "reference": {
            "type": "link",
            "rel": "products",
            "value": "id",
            "name": "name"
          }
        },
        {
          "name": "period",
          "type": "select",
          "options": {
            "pay_period": "Pay Period",
            "lifetime": "Lifetime"
          },
          "visibility": {
            "control": "type",
            "values": [
              "sales",
              "group_sales"
            ]
          }
        },
        {
          "name": "quantity",
          "type": "number",
          "visibility": {
            "control": "type",
            "values": [
              "sales",
              "group_sales"
            ]
          }
        },
        {
          "name": "max_leg_percent",
          "type": "number",
          "visibility": {
            "control": "type",
            "values": [
              "group_sales"
            ]
          }
        }
      ]

As you can see the field "type" has several values. The dynamic fields have a property "visibility" which references the control whose value determines whether or not it is visible/available. The "values" is an array of values in which the control is available if the "type" field has that particular value selected.

Perhaps "visibility" isn't the best word and "availability" would be better or something else. Does anyone have thoughts on this or has anyone else implemented a solution for this?

[zdennis]

Why would the representation as returned by an API server indicate how the presentation should handle presenting information to the user? This seems better served by a client-side language that is implementing the UI.

Thoughts?

[paulwalker]

My example, and proposed topic, has nothing to do with presentation of data. It is completely about input of data. Certain input is required or not allowed depending upon the value selected from another field. This is why I mentioned the word "availability" may have been a better choice.

If the client wants to add/remove or enable/disable fields dynamically, that's completely up to the client. Or if it wants to not do anything with the presentation and instead just filter the request input to the server...shrug. The point is there are use cases in which fields are required/not applicable depending upon dynamic condition. Every form is not always a static list of fields.

[ericelliott]

Those visibility settings could easily be handled by classes and addressed using CSS. You can create a link to a CSS document that specifies visibility.

[paulwalker]

Like I said, "visibility" is probably a bad name, it seems you guys are hung up on that.

Siren has scoped http "actions" on entities. These actions include the fields that are to be sent with the actions. The server defines what data fields are applicable to what actions, this is not simply a UI thing. Sometimes the fields are required, sometimes they are optional...again the server completely defines this and it is information valuable to a client in presentation of the UI.

Sometimes the condition that makes a field required or optional or applicable at all for a particular action is dependent upon a value inputted in another field.

Let's take a simple example...the inputting of an address. There is a state/province field. Depending upon the input of that field, there may or may not be a postal code field. And if there is a postal code field, let's pretend we want to give the list of applicable values (from a lookup url or otherwise).
(I am in no way endorsing such a robust implementation of address inputting)

[paulwalker]

How the client decides to deal with the data about input is, of course, up to the client. Whether it wants to use style sheets or not is certainly not something I want the server Siren response to have any knowledge of, let alone whether or not CSS is applicable to the client.