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

[Darran Lofthouse]

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 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.
>>>
>>
>
>