[wildfly-dev] A write-attributes op, and dealing with complex attribute paths

[Brian Stansberry]

This is a separate topic from the previous thread, so renaming. 
Bottom-post below...

On 12/10/14, 6:02 PM, Brian Stansberry wrote:
> On 12/10/14, 5:37 PM, David M. Lloyd wrote:
>> On 12/10/2014 05:35 PM, Brian Stansberry wrote:
>>> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>>>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>>>>> On 12/10/2014 10:30 AM, Brian Stansberry wrote:
>>>>>>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote:
>>>>>>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote:
>>>>>>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote:
>>>>>>>>>>> Why not something along the lines of
>>>>>>>>>>> :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})?
>>>>>>>>>>> Internally that could create a composite for us, giving complex
>>>>>>>>>>> attribute functionality while avoiding the messy resource
>>>>>>>>>>> descriptions
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On the branch of the thread where I'm discussing with Tomaz, he
>>>>>>>>>> raised
>>>>>>>>>> the same idea, which I think is a good one. I think a
>>>>>>>>>> "write-attributes"
>>>>>>>>>> with no relationship to attribute-group makes more sense though.
>>>>>>>>>
>>>>>>>>> I agree.  I have always felt that we should allow more than level of
>>>>>>>>> grouping.
>>>>>>>>
>>>>>>>> Did you mean "should NOT allow"?
>>>>>>>
>>>>>>> No, I mean multiple levels _should_ be allowed, just with multiple
>>>>>>> qualifiers.  Multiple attribute writing per resource _should_ be
>>>>>>> allowed
>>>>>>> regardless of the depth or mixture of nesting.
>>>>>>>
>>>>>>> I.e. I should be able to do something like :write-attributes({"foo" =
>>>>>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard
>>>>>>> necessary to deal with attribute group navigation.
>>>>>>>
>>>>>
>>>>> Hmm that nested syntax is an orthogonal feature IMO. I think that
>>>>> requires a lot more thought, as its basically inventing another nested
>>>>> dmr-path grammar. Not to say that we shouldn’t have that I just see
>>>>> rabbit hole there.
>>>>>
>>>>
>>>> Weird timing. I'm writing the JIRA for "write-attributes", trying to be
>>>> precise, and I just now hit that rabbit hole.
>>>>
>>>> We already have the syntax, but it's used in the *value* of the "name"
>>>> parameter to "write-attribute". Here we are using it in the parameter
>>>> *name*. That makes it impractical to have a proper list of
>>>> request-properties (aka params) in the read-operation-description output
>>>> for the write-attributes op registered against a given address. Without
>>>> that syntax, the parameter list would look much like the parameters for
>>>> the resource's "add" operation.
>>>>
>>>> Further down the rabbit hole, thinking about this earlier I realized the
>>>> read-operation-description output for the "write-attribute" operation is
>>>> not as good as it could be. For any given resource, the description of
>>>> the "name" parameter could/should include the legal values, i.e. the
>>>> names of the writable attributes. We don't do that, and now we really
>>>> can't.
>>>>
>>>
>>> I gave up writing up the JIRA, as I want it to be precise and it can't
>>> be precise enough until we have a good solution to this question. An
>>> ugly one is:
>>>
>>> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>>>
>>> That's a lot more confusing and verbose than
>>>
>>> :write-attributes(foo=123,bar.baz.zap=hello)
>>
>> I guess I missed a beat; why can't we do the latter?  Is it because of
>> the way we describe operations?  IMO this operation should be on an
>> equal footing with adding resources and we should have a uniform means
>> to describe it as such.
>>
>
> We describe the parameters to operations, including their names, and for
> all cases up to now those are easily and statically known. The CLI
> validates the parameter names used in low-level ops against the description.
>
> This can be solved by analyzing any complex attributes and outputing all
> valid paths, using syntax like [] or [?] or [*] to indicate path
> segments that represent elements in a list. We don't allow '.', '[' or
> ']' in attribute/field names, so the presence of the [ is enough to
> indicate that a list element is being described; the remaining ']', '?]'
> or '*]' are just to improve readability. I prefer a simple '[]'.
>

IMHO my post ^^^ is wrong-headed. I don't think we should try and 
describe this kind of thing this way in the operation description.

The CLI can't take an operation description listing legal values like 
bar[*].baz and use it the same way it can use plain old "bar". The 
string "bar[*].baz" is not valid input to send to the server; the user 
has to replace the * with a number. Since the CLI can't just use the 
string as is, there's not much benefit sending a bunch of text from the 
server.

Fundamentally, the CLI needs to specially handle the parameter names for 
the "write-attributes" op, and the value for the "name" parameter for 
the "write-attribute" op:

1) There needs to be special tab completion behavior. For example, after 
the user types 'bar', if they hit tab, in the write-attributes case, the 
output is

. =

This reflects that the user can either provide a deeper path into the 
complex attribute, or move on to specifying the value of param "bar".

In the write-attribute case, after the user types name=bar and hits tab, 
the output is:

. ,

Comma instead of = to indicate they want to move on to the next param.

Similar stuff for the [ and ] chars when dealing with lists.

2) Before sending a low-level op, the CLI validates the op's param names 
against the param names listed in the operation description. This 
validation should understand how to validate bar[0].baz.

These two aspects of behavior could just be hard-coded into the CLI. To 
be formal though, we could add a couple pieces of boolean metadata to 
the parameter description:

a) one indicating that the parameter name itself can be expanded into a 
deeper path. This would be used in the params to the "write-attributes" op.
b) one indicating that the parameter value can be expanded from the 
formally specified legal values. This would be used with the "name" 
param for the "write-attribute" op, if we ever improved its description 
to properly list the legal values.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat