-
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
conditional fields in actions #38
Comments
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? |
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. |
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. |
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). |
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. |
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:
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?
The text was updated successfully, but these errors were encountered: