Re: [wildfly-dev] Management model attribute groups
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(a)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