You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the property above, the namespace suffix is also an indication of the type of value for the property.
I'm thinking it would make a lot of sense to specify the type directly in the key:
recalled_product.boolean = true | false -> the UI can handle displaying and inputing in different languages
recalled_product.date : the UI knows it's a date, so it can display a calendar
recalled_product.link : the UI knows it's a link, so it can display it as a link
Other useful types:
some_property.string
some_property.string:fr -> French value for the string (as suggested by Charles in #17)
number_of_units.integer
We could try to indicate "dimensions" as well:
packaging:width.length + packaging:height.length + packaging:length.length : all 3 properties are of the "length" dimension.
price_on_packaging.price : the propert is a price
And something that would be immensely useful is to allow taxonomies in types:
packaging:main_color.taxonomy:colors : the UI would allow input and output of "Blue" in any language
Something else that would be very tempting is to indicate in the property key name if it can have multiple values or not.
e.g. "packaging:colors.taxonomy:colors@" -> the @ (or any other sign or scheme) indicates that the property can have multiple values.
Of course all this should be transparent to users, they won't have to deal with the : , the . or the @, the UI will take care of it.
This is related to the namespace discussion in #17
@CharlesNepote 's example use of namespace was:
"recalled_product" => "yes"
"recalled_product:date" => "2021-05"
"recalled_product:link" => "https://rappel.conso.gouv.fr/fiche-rappel/383/Interne"
For the property above, the namespace suffix is also an indication of the type of value for the property.
I'm thinking it would make a lot of sense to specify the type directly in the key:
recalled_product.boolean = true | false -> the UI can handle displaying and inputing in different languages
recalled_product.date : the UI knows it's a date, so it can display a calendar
recalled_product.link : the UI knows it's a link, so it can display it as a link
Other useful types:
some_property.string
some_property.string:fr -> French value for the string (as suggested by Charles in #17)
number_of_units.integer
We could try to indicate "dimensions" as well:
packaging:width.length + packaging:height.length + packaging:length.length : all 3 properties are of the "length" dimension.
price_on_packaging.price : the propert is a price
And something that would be immensely useful is to allow taxonomies in types:
packaging:main_color.taxonomy:colors : the UI would allow input and output of "Blue" in any language
Something else that would be very tempting is to indicate in the property key name if it can have multiple values or not.
e.g. "packaging:colors.taxonomy:colors@" -> the @ (or any other sign or scheme) indicates that the property can have multiple values.
Of course all this should be transparent to users, they won't have to deal with the : , the . or the @, the UI will take care of it.
What do you think?
Part of
The text was updated successfully, but these errors were encountered: