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

On 15/11/13 14:32, Brian Stansberry wrote: > I'm for consistency, mostly because when we use resources and when we > use map attributes is pretty arbitrary now. Not sure if I would go that far, I know recently I have used resources where I really wanted the properties to be manageable independently of each other.

> 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. >>> >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev