Re: [wildfly-dev] Management model attribute groups

> 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: >> Forgot to hit "reply to list" on this one. >> >> 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: >>>>>> >>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>> Off and on we've had discussions around the idea of "attribute groups". >>>>>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>>>>> like to propose doing something concrete but simple for these for WF 9, >>>>>>> ideally in the next month. >>>>>>> >>>>>>> A big part of my goal here is to ensure that whatever we do doesn't >>>>>>> preclude something more advanced in any next generation management >>>>>>> stuff, e.g. David's stuff. >>>>>>> >>>>>>> PART I Concepts >>>>>>> >>>>>>> 1) What is an attribute group? >>>>>>> >>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>> attributes associated with the same resource type that are independently >>>>>>> configurable but are statically declared to be conceptually related. The >>>>>>> group has a name, and members. The name provides a brief indication of >>>>>>> the nature of the relationship. >>>>>>> >>>>>>> The goal is to provide information to the user to help them better >>>>>>> understand the relationship between attributes. In particular, >>>>>>> management tools could use this information to visually present related >>>>>>> attributes together, e.g. in a tab or other grouping widget in the web >>>>>>> console. >>>>>>> >>>>>>> 2) What isn't an attribute group? >>>>>>> >>>>>>> Something relevant to writes. >>>>>>> >>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>> >>>>>>> Because the attributes control a discrete piece of functionality and you >>>>>>> need to be able to turn that on or off as a unit. So you add/remove the >>>>>>> resource. >>>>>>> >>>>>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>>>>> n>1 simple attributes in a group. >>>>>>> >>>>>>> a) Because the attributes control a discrete piece of functionality and >>>>>>> you need to be able to turn that off as a unit. So users can undefine >>>>>>> the complex attribute. >>>>>>> >>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>> fields should be done atomically and you don't want to force users to >>>>>>> use a CLI batch. So you let them use write-attribute and specify the >>>>>>> value of all the fields. >>>>>> 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. >> > > 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.