Specifying Checkbox and Radio Fields

424 views
Skip to first unread message

Kevin Swiber

unread,
Apr 23, 2016, 1:42:57 PM4/23/16
to siren-hy...@googlegroups.com
Howdy folks!

Specifying how checkbox and radio fields look in Siren is long overdue.  I'd like to propose the following format, which I'm using today.

Checkbox example:

"fields": [
  {
    "name": "color",
    "type": "checkbox",
    "title": "Choose a Color",
    "value": [
      { "title": "The Color Red", "value": "red" },
      { "title": "The Color Blue", "value": "blue", "selected": true },
      { "title": "The Color Green", "value": "green", "selected": true }
    ]
]

Radio example:

"fields": [
  {
    "name": "color",
    "type": "radio",
    "title": "Choose a Color",
    "value": [
      { "title": "The Color Red", "value": "red" },
      { "title": "The Color Blue", "value": "blue", "selected": true },
      { "title": "The Color Green", "value": "green" }
    ]
]

I've found this to be the most flexible and understandable solution.

Thoughts?  I'd like to move forward with this as soon as possible.


Thanks,

Kevin

Manuel Gómez

unread,
Apr 23, 2016, 2:17:04 PM4/23/16
to siren-hy...@googlegroups.com
On Sat, Apr 23, 2016 at 1:12 PM, Kevin Swiber <ksw...@gmail.com> wrote:
> Checkbox example:
>
> "fields": [
> {
> "name": "color",
> "type": "checkbox",
> "title": "Choose a Color",
> "value": [
> { "title": "The Color Red", "value": "red" },
> { "title": "The Color Blue", "value": "blue", "selected": true },
> { "title": "The Color Green", "value": "green", "selected": true }
> ]
> ]
>
> Radio example:
>
> "fields": [
> {
> "name": "color",
> "type": "radio",
> "title": "Choose a Color",
> "value": [
> { "title": "The Color Red", "value": "red" },
> { "title": "The Color Blue", "value": "blue", "selected": true },
> { "title": "The Color Green", "value": "green" }
> ]
> ]
>
> I've found this to be the most flexible and understandable solution.

Indeed it’s very flexible and might work fine, but I would propose, if
only for the sake of argument, this more restrictive alternative,
although such a restriction may turn out undesirable:

Radio example:

"fields": [
{
"name": "color",
"type": "radio",
"title": "Choose a Color",
"value": {
"red": { "title": "The Color Red" },
"blue": { "title": "The Color Blue", "selected": true },
"green": { "title": "The Color Green" }
}
]

This assumes duplicate values would make no sense or would be
undesired. I do not know if there are use cases for multiple
alternatives with the same `value`, but if there are, this proposal
would of course be inferior to the one with an array.

Dietrich Schulten

unread,
Apr 24, 2016, 5:06:33 AM4/24/16
to Siren Hypermedia
+1 for Kevin's proposal

Example use case for multiple  alternatives with the same `value`:

Rental Car Type Limousine

Options
[  ] Child seat
[  ] Child seat
[  ] Child seat
[  ] Navigation system

The main argument however is that html places no such restriction on checkbox values, so IMO we should not do it either. If it is possible in HTML, then people will want to do it.

J Fernandes

unread,
Apr 26, 2016, 3:49:51 AM4/26/16
to siren-hy...@googlegroups.com
+1 and looking forward for further developments!
--
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/6d2868cd-d909-4539-a390-fbf80b0802f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kevin Swiber

unread,
Apr 27, 2016, 2:03:24 PM4/27/16
to siren-hy...@googlegroups.com
I'll try to get a Pull Request ready this weekend.  If someone has time to beat me to it, I'd be thrilled.  :)

Side note: We still need better definition around other input fields, as well, such as `range`.

To view this discussion on the web visit https://groups.google.com/d/msgid/siren-hypermedia/6AD423D2-452E-46D2-A071-0FEC537913D1%40gmail.com.

Dietrich Schulten

unread,
May 2, 2016, 2:16:33 PM5/2/16
to Siren Hypermedia
Hi Kevin,

What do you think of this: https://github.com/kevinswiber/siren/pull/69? Do we need to clarify if clients may ignore value objects?

I've extended the example at the beginning and added a section Value Objects inside the fields section. The class attribute of fields was enclosed in tickmarks, I've removed those, they seemed to be a typo.

How should we go about the other HTML5 input field attributes? Should the spec say that the server may use them and the client may ignore them?

Best regards,
Dietrich


mca

unread,
May 2, 2016, 6:32:01 PM5/2/16
to siren-hy...@googlegroups.com
when adding functionality to the spec, I think it's important to address whether the additions are "breaking" or "backward-compatible" 

in general that means adding checkbox/radiofield types to the spec has an immediate effect on any existing Siren client implementation's "compliance" status. 

If support for the "checkbox" or "radio" field types is REQUIRED then any existing client (before the added functionality) is now "non-compliant". 
if support for these new field types is OPTIONAL or RECOMMENDED then existing clients are then "conditionally compliant."

this is a challenge all specs face and getting some basics in place for Siren would be very valuable.  something along the lines of what appears in the UBER format spec[1] is needed, i think. There likely should be something on extensibility[2], too. but that's a slightly diff discussion.





--
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/1b669646-d558-4019-8bb1-fe7c0686e7bd%40googlegroups.com.

Dietrich Schulten

unread,
May 12, 2016, 12:52:12 AM5/12/16
to Siren Hypermedia
Thank you Mike for the feedback. Keeping APIs compatible is worth an engineering discipline of its own ;-)

The radio and checkbox types have been around previously. It was however not specified how the server can present possible checkbox values, so that the client can send a list of possible values. Similarly, the server could not tell the client that one out of multiple values is expected. Having multiple names for an input is forbidden, so it is impossible to repeat the name, which would have been more similar to a HTML input.

Existing servers can emit siren checkboxes or radio inputs with a single value today, but without a relationship between the single inputs. Such a server would break clients that are unaware of value objects, if it suddenly returns a checkbox/radio value object with possible values instead of a single value, for an input that previously.was a single-value input. OTOH Kevin's suggestion (which I wrote down in the pull request) has also been around for a while, he suggested the same thing in the past for this problem, so maybe we are just making a common practice an "official one".

Even if we had a statement that clients must ignore elements they do not understand, the server could not do this. Also, a completely new attribute (e.g. select) would not allow the server to switch.

@Kevin:
Siren is versioned, but I do not know how breaking changes were handled in the past. 

@mamund:
In Uber, when you changed the meaning of model, the Uber version stayed the same. How did you handle the breaking change for Uber?


mca

unread,
May 12, 2016, 1:23:49 AM5/12/16
to siren-hy...@googlegroups.com

@dshulten:

when we broke/forked the media type definition (e.g. introduced non-backward compatible changes) we changed the media type string.

the intial media type identifier was:
application/vnd.amundsen-uber+xml (and +json)

when we modified the use of model and template, it was changed to:
application/vnd.uber+xml (and +json)

if/when it levels up to a fully-spec'd IETF format, we'll drop the vnd. facet and it will be:
application/uber+xml and (+json)

this means all identifiers can exist side-by-side and that client apps built for a single identifier string will continue to work in the future.

--
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/c4abab49-1857-4985-ab21-97c7260b5d16%40googlegroups.com.

Ahmed Agabani

unread,
Jul 30, 2016, 10:35:17 AM7/30/16
to Siren Hypermedia
Line 53 and line 59 of https://github.com/dschulten/siren/blob/5e15b2ca6e91bb1d2fa91b5629fc2638fd10141d/README.md violates siren 0.6.1 spec

A name describing the control. Field names MUST be unique within the set of fields for an action. The behaviour of clients when parsing a Siren document that violates this constraint is undefined. Required.

nikla...@grandcentrix.net

unread,
Jan 23, 2017, 11:03:33 AM1/23/17
to Siren Hypermedia
Hi everyone,

I'd like to kindly ask for an update on this issue, since I need to represent possible radio values in my current sprint ;-)

I think that pull request 69 [1] is a nice solution that fits our needs.

It would be nice to know whether this will be merged into the official specification or if we have to fork our own extended spec.

Greetings
Niklas Wulf


Kevin Swiber

unread,
Jan 23, 2017, 1:49:58 PM1/23/17
to Siren Hypermedia
Hey Niklas,


If you proceed with implementing it as specified in PR#69, I think we'd all benefit.  I've implemented PR#69 in an API, but I haven't had to deal with many use cases.  If you can move forward with that, reporting any issues you encounter, I think we'd all be in a better spot.

Best Regards,

Kevin

+++ Das grandcentrix Headquarter zieht um! Ab dem 01. Juni 2017 finden Sie uns Am Holzmarkt 1 in Köln. +++

grandcentrix GmbH
Schanzenstrasse 6-20
51063 Köln, Deutschland

phone: +49 221 677 860 0

Amtsgericht Köln | HRB  70119 | Geschäftsführer: R. Rottmann, M. Willnow | USt.-IdNr.: DE266333969

--
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/8290252e-95b8-4a68-b58b-98a0ea9e947b%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages