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

[Brian Stansberry]

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