Re: [wildfly-dev] Management model attribute groups

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.