Action fields and enumeration

404 views
Skip to first unread message

Gabriel Castillo

unread,
Feb 3, 2014, 7:21:37 PM2/3/14
to siren-hy...@googlegroups.com
One thing we've implemented on action fields (in a rather half-ass way) are enumeration types.  For this we've added an "options" attribute on the field.  An example direct from our API:

fields: [
{name:sendRepaymentNotifications, type:radio, options:[monthly, nightly, none]}
{name:sendAutolendingNotifications, type:radio, options:[monthly, nightly, none]}
]

Any feedback on this approach before I make a pull request to have an optional "options" array on fields?

Alex Soto

unread,
Feb 3, 2014, 8:25:34 PM2/3/14
to siren-hy...@googlegroups.com
see my comment on the other thread you posted to as well.


--
You received this message because you are subscribed to the Google Groups "Siren Hypermedia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to siren-hypermed...@googlegroups.com.
To post to this group, send email to siren-hy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/siren-hypermedia/1fbd2157-740a-44a0-8416-e4272736fddd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Gabriel Castillo

unread,
Feb 3, 2014, 8:37:39 PM2/3/14
to siren-hy...@googlegroups.com
I should also clarify that we don't use the "select" field type.  Instead, if a user can select multiple options we would use the "checkbox" field type.  

Some additional points on this:

1) We figured that what we were really trying to express was enumeration (but there is no enum input type in html) and that we should leave the question of wether its actually displayed as a checkbox or select is a UI decision.

2) Chosing to stick with radio and checkbox was arbitrary, we could have gone with select and multi-select, or we could have just not imposed that constraint - we just didn't want multiple ways of expressing the same thing

Kevin Swiber

unread,
Feb 3, 2014, 8:46:53 PM2/3/14
to siren-hy...@googlegroups.com
I've also made up ways to do this in the past.  This is one important part of the spec that has not been specified and something we need to hammer out.

My version of this has been:

"fields": [
  { "name": "color", "type": "radio", "value": [ { "value": "red" }, { "value": "blue", "selected": true }, { "value": "green" } ] }
]

I'm not sure I have any good feedback at this point.  I just know both of these feel wrong.  :)

Open to suggestions.

--
Kevin Swiber
Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

Pat Cappelaere

unread,
Feb 4, 2014, 8:12:31 AM2/4/14
to siren-hy...@googlegroups.com
Kevin,

I am just curious.  I do not want to pick on you and this is a more general question to the group.
Is there some anti-API Discovery Service Document feeling on this list?

It seems to me that having such a document available for your service is extremely important.
It kicks starts your documentation and API explorer.
The schema you develop can be used to define your actions (both inputs and outputs) as well as your security model.
This would be a great extension to Siren, Hal or Activity/Action Streams (and lower bandwidth consumption)
It is very well documented and in operational use (https://developers.google.com/discovery/)
It certainly does not require you to be part of the Google eco-system either.
So I am puzzled.
Why not?

Many thanks,
Pat.

--
You received this message because you are subscribed to the Google Groups "Siren Hypermedia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to siren-hypermed...@googlegroups.com.
To post to this group, send email to siren-hy...@googlegroups.com.

Kevin Swiber

unread,
Feb 4, 2014, 9:38:47 AM2/4/14
to siren-hy...@googlegroups.com
To add a suggestion as a response to my own open call for suggestions...

"fields": [
  { "name": "color", "type": "radio", "value": "red" },
  { "name": "color", "type": "radio", "value": "blue", "selected": true },
  { "name": "color", "type": "radio", "value": "green" }

For application/x-www-form-urlencoded, this could translate to:

color=blue

In the case of a multi-select...

"fields": [
  { "name": "color", "type": "checkbox", "value": "red" },
  { "name": "color", "type": "checkbox", "value": "blue", "selected": true },
  { "name": "color", "type": "checkbox", "value": "green", "selected": true }

it could translate to:

color=blue&color=green

I believe many server-side frameworks convert this into an array.

Thoughts?

Gabriel Castillo

unread,
Feb 6, 2014, 2:38:17 AM2/6/14
to siren-hy...@googlegroups.com
Just cause I felt like making things a little more murky...

I know the "required" attribute isn't officially part of the Siren spec but I find it useful.  On that note, if the "required" attribute becomes part of the Siren spec, how would we show that at least one of the checkboxes is required?  (Maybe we don't care about that use-case right now?)

Another one I find useful but not sure how much we care about at this point is the use case that Manual Gomez brought up (https://groups.google.com/d/msg/siren-hypermedia/JuAW9qryPn4/ooxotIj6T30J) where a checkbox or radio field references a url for its list of options.  What would be the right way to reference such a list of options?  I currently do it in the "links" array of the parent model, but this is kinda lame in that the consumer doesn't know to look there.  My use case is a very long and dynamic list of localities.


Dietrich Schulten

unread,
Apr 23, 2016, 2:28:04 AM4/23/16
to Siren Hypermedia
+1 to follow the HTML form mechanisms for radio buttons and checkboxes closely. Everybody understands them, and clients who choose to generate an HTML form from the siren response have an easy life. 
Unfortunately the spec explicitly forbids repeated field names right now:

"A name describing the control. Field names MUST be unique within the set of fields for an action. " 

Kevin Swiber

unread,
Apr 23, 2016, 1:44:29 PM4/23/16
to Siren Hypermedia
Hey Dietrich,


Thanks for your input.

Regards,

Kevin

--
You received this message because you are subscribed to the Google Groups "Siren Hypermedia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to siren-hypermed...@googlegroups.com.
To post to this group, send email to siren-hy...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages