7:14 p.m.
Please search for uses of the ParameterCorrector interface. Its function
is to allow server side handlers to adjust things.
This should not be part of WFCORE-74. It's a separate, more far reaching
task.
In general I don't think this kind of client side validation is worth
the loss of flexibility. We have tab completion to help suggest correct
values.
Min/max validation is least likely to introduce problems.
Just dreaming, I can imagine an enum value being dropped from the list
of "legal" values, but the OSH still accepts/translates the old value to
provide compatibility for old scripts. That's somewhat broken and is a
bit of a corner case, but it's another example of how the server can be
"forgiving."
What sort of path validation did you have in mind? The remote client
cannot know what filesystems are in use in all possible locations
affected by an op, so I don't see how it can validate.
On 8/10/15 11:53 AM, Emmanuel Hugonnet wrote:
Hi,
I'm currently working on adding more metadata on resource attributes and operation
parameters or replies [1].
As an example I added the fact that an attribute of type STRING is in fact a filesystem
path or an URL [2].
To show how this kind of metadata could be helpful I have updated the CLI so that it uses
the filesystem path completer and to try to
validate the operation parameters :
for example checking that an URL has a correct format before executing an operation.
This led me to provide more validation : checking that an integer is in the valid range,
etc.
Brian rightfully pointed out that in some case we are defining than an operation
parameter is defined a certain type while the handler
supports multiple types :
for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object
but supports getting the object directly.
So I'm wondering about adding support for range or type validation for
'complex' types as it may break existing valid (as in accepted even
if wrong) operations.
What do you think ? Do you see other edge cases like this one ?
Emmanuel
1: https://issues.jboss.org/browse/WFCORE-74
2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat