rest
rest copied to clipboard
Clarification: Priorities of parameter conversion rules
In the specification we do list different ways of converting a String to a parameter. A user recently asked, if the sequence mentioned in the spec is actually a mandatory priority? Actually it is necessary to know the sequence of priorities in case multple rules do match a parameter, e. g. there is a publis String constructor and a valueOf-Method and a param converter.
As it is not explicitly mentioned by the spec, we should add a note that the sequence is mandatory and re-order it like this:
- ParamConverter -- it makes no sense to explicitly register these, if not preferring it over all other rules.
- fromString, valueOf -- it makes no sense to have these seldomly found methods, if not preferring it to constructors.
- String-consuming constructor -- as this is the most simple attempt, it should be used only if no more complex solution exists.
Not directly answering the question, but I still would love to have these concerns split off to a separate converter spec. We're seeing similar issues and questions in e.g. Jakarta Faces.
+1 for supporting such a spec once it is there, but for the time being readers of the spec need an unambiguous answer on the originl question
@jansupol @andymc12 @chkal @spericas Is this core proposal OK for you then please briefly confirm, so I will turn it into a MR. Thanks.
I'm fine with your proposal of enforcing the order as currently listed in the spec. :+1:
I was under the impression that the Spec already defines the order in Section 3.2. String consuming argument has priority to fromString, valueOf. I am not convinced that the change of order - another incompatibility - would help the users.
The spec lists the types that are supported in connection with those "injection" points. It sort of establishes an order for how the conversion should proceed (should more than one alternative is available), but it is not very explicit. I'm fine with the proposal.