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

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 '[]'.