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&gt; 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?