Re: [wildfly-dev] Management model attribute groups

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