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

[Kabir Khan]

On 15 Nov 2013, at 14:32, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> 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

Also, in the transformers it is a total nightmare moving from: 
	type=foo:write-attribute(name=things,value={a=2,c=3})
to
	type=foo/thing=a:write-attribute(name=value,value=2)
	type=foo/thing=b:remove
	type=foo/thing=c:add(value=3)
i.e. transforming from the latter to the first

> 
> 
> 
> 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 at gmail.com
>> <mailto:tomaz.cerar at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev