Re: [wildfly-dev] Management model attribute groups

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.

Having a special operation that "knows about" attribute groups in some special way is thus precluded; simply having a multiple "write-attributes" fits in nicely with the concept that a resource is actually our basic atomic unit of granularity.