Re: [wildfly-dev] Management model attribute groups

On 12/10/14, 10:02 AM, David M. Lloyd wrote: > On 12/10/2014 08:21 AM, Brian Stansberry wrote: >> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: >>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? >> >> This is what I meant by >> >> "4) Low level management API >> >> The output of read-resource and read-resource-description is modified >> such that attributes are sorted by group name and then by attribute name." >> >> I used the verb "sorted" though because I have no intent of modifying >> the output structure by creating a level for the attribute group. That >> would be an incompatible change in the output format and would obscure >> the distinction between an attribute group and a complex attribute. > > FWIW I think this is a good distinction and a good approach. > >>> Is aliasing to be supported ? What if I want to change the attribute group name ? >>> >> >> Good question. >> >> Heiko, I don't think Emmanuel is talking about users changing this. We >> use aliasing in other contexts as a mechanism for maintaining >> compatibility. If something is poorly named (e.g. a bad resource address >> name) we can fix it in a later release but also register an alias under >> the old name to provide compatibility. >> >> I don't see how aliasing could work here. Only thing I can imagine is >> using it in the ls -l output, such that the same attribute can appear > >> 1 times, if it is associated with more than 1 group. I suppose a console >> could do a similar thing, but I don't at all regard maintaining that >> kind of compatibility in UI layout to be a requirement. >> >> I'm not sure how much we regard consistency in the ls -l output across >> releases as being a requirement. I think of that as being an output >> format for humans, not machines. >> >> Aliasing is an example of a reason for allowing an attribute to belong >> to more than one group. There may be others. Perhaps as an aid to querying? > > I still feel strongly that we should look to real resource versioning as > the proper solution here, though I realize there has not been a > satisfactory resolution to this discussion. But the longer we don't > come to a resolution, the more (arguably questionable) tricks we have to > pull to manage compatibility. > Agreed, at least re: we need to come to a resolution and that I don't want to add further tricks. So I don't see the aliasing use case as being a sufficient justification for allowing an attribute to be associated with > 1 group.

The (vague) querying notion is more interesting to me as a reason for allowing > 1 group. Really all I've described here is a form of tagging attributes. However, separating "tags" for querying from "attribute-group" which is specifically intended as a primary grouping clue for management UIs is IMO better.