[wildfly-dev] Management model attribute groups

[David M. Lloyd]

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.

> 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?

-- 
- DML