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

[Brian Stansberry]

On 11/15/13 8:50 AM, Darran Lofthouse wrote:
> 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.
>

It's pretty arbitrary. :) That doesn't mean there's no rationale for 
anything. Just that you won't find consistent application of a rationale 
across the server.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat