[wildfly-dev] Proposal for improving handling complex types in CLI

[Brian Stansberry]

On 8/18/14, 3:01 AM, Heiko Braun wrote:
>
> I've already commented on the gist, but for the record here's my point
> if view:
>
>
> +1 on the custom operation for list/map modifications.
>
> But I am against the write-attribute changes and generic complex
> attributes . IMO we'd better be explicit about complex attributes and
> limit it to certain usecases:
>
>   * write-attribute is for simple attributes only and yields an error
>     for complex types

We couldn't do this for compatibility reasons, even if the only complex 
attributes left were legacy aliases for resources.

>   * no support for generic complex attributes. these should become
>     (child) resources themselves

I want a resource to have some meaning to an end user as an independent 
manageable entity. An internal data structure that's simply part of the 
configuration of some other entity isn't an independently manageable 
entity. So, a big part of Tomaz's brief in this task is to:

a) Drive a better clarification of the boundaries of what an 
"independent manageable entity" is. In the "squatter resource" 
discussion for example, David had what looked like a pretty limited take 
on what was "independent". The other end of the spectrum would be 
something that should be added/removed from the config as a unit but 
doesn't actually result in any distinct services. Heiko, you're on this 
end of the spectrum.

I want Tomaz to find and illustrate the cases in between and see if we 
can come up with some concrete criteria.

You guys have already done a great service here with your analysis of 
the model.

b) See where we have complex attributes that really are independent 
manageable entities, and thus should be resources. (We'll fix these, but 
that's not part of the immediate requirements/design task.)

c) See where we have resources that aren't indepedent and thus should be 
represented as attributes. (We *may* fix these, but that's not part of 
the immediate task.)

d) If we end up with any complex attributes left (besides simple lists 
and maps), sort out with your team what API support you need to be able 
to deal with them. If converting something that's not independent to a 
child resource makes your life easier because you can use 
read-resource-definition etc, then we need equivalent ops for complex 
attributes.


In the past we've had some complex attributes that exist primarily to 
support changing multiple fields in an atomic step. For example "time" 
and "unit" combined in single attribute.[1] Since the CLI batch command 
and the underlying composite op let users make multiple changes 
atomically, this kind of thing is IMHO an insufficient reason for a 
complex attribute or a child resource.

Simple conceptual grouping of related attributes is an insufficient 
reason for either a child resource or a complex attribute. We'll 
introduce a new bit of metadata to use for grouping.


[1] Side note: I don't think 'time' and 'unit' are very compelling as an 
complex attribute; I just mention it as an understandable example.

>   * introduce an explicit ModelType.LIST and ModelType.MAP (i think the
>     former already exists)
>
>
>
> /Heiko
>
>
> On 14 Aug 2014, at 18:31, Tomaž Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>> wrote:
>
>> Hi guys,
>>
>>
>> there ware some discussions on how we should improve handling complex
>> types of attribute bit better in CLI.
>> For most part that was about Map & List types.
>>
>> After some discussions with few of you I came up with plan / ideas
>> what all options are there for us to improve on.
>>
>> you can see current state of proposed enhancements at
>> https://gist.github.com/ctomc/91055a6f4e7502dcd130
>>
>> In short, I propose to add set of map-* and list-* global operations
>> and improve :read-attribute & :write-attribute
>> with EL like syntax for reading / updating map, list and generic
>> complex attributes.
>>
>>
>> Let me know what you think about it, especially Console & CLI folks.
>>
>> --
>> tomaz
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat