[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 5:34 PM, David M. Lloyd wrote:
> On 12/10/2014 05:27 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>>>> 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.
>>>>
>>>> Gotcha, and I agree. Thanks for clarifying.
>>>
>>> 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.
>
> Why does it make a difference?  The attribute names would be "a.b.c"
> instead of just "a", but I don't see that as an impracticality.
>

IIRC the syntax also allows list indexing, so it's not static.

>> Withoutthat syntax, the parameter list would look much like the parameters for
>> the resource's "add" operation.
>
> Why is that a problem?  It's essentially the same thing in most cases,
> isn't it?
>
>> 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.
>
> Why not?
>


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