Skip to content
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

Typos in type definition #88

Open
Ickbinet opened this issue Nov 1, 2021 · 6 comments
Open

Typos in type definition #88

Ickbinet opened this issue Nov 1, 2021 · 6 comments

Comments

@Ickbinet
Copy link

Ickbinet commented Nov 1, 2021

https://rwcbook.github.io/hal-forms/#_code_type_code

"Possible settings for the type value adn teh expected contents to be returned inthe are:"

Should be?:

"Possible settings for the type value and the expected contents to be returned in here are:"

@odrotbohm
Copy link

It might also be a good chance to add a note on whether the list of possible values for type is exhaustive. That list is very close to HTML input types except checkbox, radio and file. Are other types generally supported, too?

@mamund
Copy link
Owner

mamund commented Nov 1, 2021

update got reverted somehow. will fix

and, yes, we should state that "type" list is not exclusive. with a fallback for when client's don't recognize the value of "type"

@odrotbohm
Copy link

Should we remove the sentence about type being an "enumerated attribute"? It's that one, that led me to assume exhaustiveness of the list given. Because, if arbitrary other types are allowed as well, there's no enumeration anymore, is there?

@mamund
Copy link
Owner

mamund commented Nov 1, 2021

removing would be OK w/ me. AFAIK, the word's definition does not call for exhastiveness. but happy to improve clarity here.

@odrotbohm
Copy link

As we're following concepts of HTML pretty closely I had assumed it was a reference to the concept of an enumerated attribute like this: https://stackoverflow.com/questions/4104110/what-are-enumerated-attributes-in-html

@mamund
Copy link
Owner

mamund commented Nov 1, 2021

that's a very reasonable assumption. i agree that we should drop "enumerated". it's a small change for a big win.

odrotbohm added a commit to spring-projects/spring-hateoas that referenced this issue Nov 2, 2021
As per the discussion in mamund/hal-forms#88, the list of property types in HAL FORMS is not exhaustive. This means we cannot align them with HTML input types and even more so not drop anything not an HTML input type.

This is now implemented by switching to generic Strings in the HAL FORMS property DTO and directly piping the value originally registered on the affordance into it.
odrotbohm added a commit to spring-projects/spring-hateoas that referenced this issue Nov 2, 2021
As per the discussion in mamund/hal-forms#88, the list of property types in HAL FORMS is not exhaustive. This means we cannot align them with HTML input types and even more so not drop anything not an HTML input type.

This is now implemented by switching to generic Strings in the HAL FORMS property DTO and directly piping the value originally registered on the affordance into it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants