On 12/10/14, 9:22 AM, Kabir Khan wrote:
>
>> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry@redhat.com> 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.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev