MapsTo ideas from Hyperdescribe discussion
fosdev opened this issue · comments
Three things to ensure we address:
- Hyperdescribe ability to map to a different attribute (?q}, but have "query" as the name of the field, e.g. ?q={query}
- Scope of applicability (uri template, body, both, neither)
- Instructions for PUT related/replace related endpoints that instructs a client to build the complete resource and send it without overloading "required" constraint/validators. Is there use for a hidden field concept? E.g. field you cannot update that is set/generated by service. Is that part of the resource you are replacing?
Just perusing this repo and saw this issue and thought I'd add a note on item 3 and the hidden fields. In Hyperdescribe, I was toying with this idea of immutability of form fields. I am not sure I really accomplished my goal (one of the many reasons I'm not at 1.0 for Hyperdescribe), but I used a couple of values:
defaultValue- This was a hint at what the default value for the field is. This allowed me to set a field as required and give a default value, or even treat a field somewhat like a<select>and set one of the options as selected.value- This is the value of the field, and if set, is considered immutable. This means that I could add a CSRF token much like Rails does and the client would treat like a hidden field.
Then there is mapsTo, which also (sort of) allows me to specify what the current value of the field/parameter is.
Just some thoughts. Might not fit, but maybe it will spark some ideas!
