Re: [wildfly-dev] Property Representation (name/value) pairs in Management model

I'm for consistency, mostly because when we use resources and when we use map attributes is pretty arbitrary now. But I don't understand why a properly described map attribute would be problematic for a console. I don't see why any attribute, no matter how complex, should be problematic for a console so long as it is fully and properly described. I'm concerned about it because breaking compatibility by completely removing the ability to treat things as a coherent map is a major reduction in usability: type=foo:add(things={a=1,b=2}) vs batch type=foo:add type=foo/thing=a:add(value=1) type=foo/thing=b:add(value=2) run-batch We get usability bug reports all the time when users need to do the latter, mostly because people omit batch/run-batch. The solution being to add a "things" param to type=foo so people can do the whole thing in one go. I'm fine with moving to consistently having subresource representation if it's critical for the console, but only if we can still support "things" as an optional param. This is also much easier: type=foo:write-attribute(name=things,value={a=2,c=3}) vs batch type=foo/thing=a:write-attribute(name=value,value=2) type=foo/thing=b:remove type=foo/thing=c:add(value=3) run-batch

On 11/15/13 2:58 AM, Heiko Braun wrote: > > > 1) PropertiesAttributeDefinition, basicly complex attribute with key & value > 2) sub resources, where key = name of resource and there is only one > attribute under it with value, for example see > PropertyResourceDefinition and its usage. This is quite common > > Consolidation on these two would already be a great help. But I would > even take it further: > > Why do we have complex attributes (ModelType.Object, your case 1) at > all? IMO the most straight forward approach would be to only allow for > attributes to be simple types (ModelType.<String|Int,Bool,etc>) and > enforce any ModelType.Object to become a sub resources (addressable). > > Mangling complex types into attributes creates a lot of ambiguity and is > the main driver for creating edge cases and workarounds. > > A word on backwards compatibility: > > We've done a fine job so far, but if we get a chance (WF.Next) we should > try to correct the model and if necessary break compatibility. > > regards, Heiko > > On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com > <mailto:tomaz.cerar@gmail.com>> wrote: > >> my intent is/was to unify most of this under #1 & #2, there are some >> good use cases for #2 but in most cases when you need any special >> handling of each and every property #1 works best and is simplest to use. >> > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev