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

[Brian Stansberry]

On 8/18/14, 9:40 AM, Tomaž Cerar wrote:
>
> As it goes for introducing ModelType.MAP I am all in favor of. As it
> would allow us also few more things when it comes to
> types of map as currently we only have support for Map<String,?> where
> key can only be String.
> Introducing ModelType.MAP would also require us to introduce few new
> model metadata constructs such as key-type.
>

Why is a new ModelType needed for this?

> I discussed ModelType.MAP with Brian a bit, but he was not big fan as
> that would require us move all map attributes to use this
> which would be a big change (100+ attributes) and this would be big
> compatibility issue.
> The biggest problem with introducing it is that any object can be
> used/addressed as map and as such having extra type bit redundant.
>
> However we could probably introduce it for WildFly 10 (maybe 9) with
> jboss-dmr 2.x series.
>

Here's why I'm not a fan:

1) A new ModelType will break every existing client out there. This is a 
huge problem, and requires an even huger benefit to justify it.

2) We already describe the types of maps at the higher level, so what's 
the big benefit of pushing something to a lower level?

Currently:

ModelType attrType = attributeDesc.get("type").getType();
if (attrType == ModelType.OBJECT) {
   ModelType valueType = attributeDesc.get("value-type").getType();
   if (valueType = ModelType.TYPE) {
      // it' a simple map
      doStuffWithMap(....);
   } else {
     // it's a complex attribute
     doStuffWithComplexAttribute(....);
   }
} else ...

With a ModelType.MAP we get

ModelType attrType = attributeDesc.get("type").getType();
if (attrType == ModelType.OBJECT) {
   // it's a complex attribute
   doStuffWithComplexAttribute(....);
} else if (attrType = ModelType.MAP) {
    // it' a simple map
    ModelType valueType = ???; // some new DMR API
    doStuffWithMap(...);
} else ...

That's a difference of 2 lines of code in a utility method, and that's 
assuming that "???; // some new DMR API"  is a single line.

3) DMR has a really simple interface -- 4 public classes, ModelNode, 
ModelType, Property, ValueExpression. To be useful, ModelType.MAP will 
require some sort of new concept, to express the type of the map value, 
and perhaps the map key. So a 25% or more increase in the number of 
types in the public API. Not a big deal by itself but it's a sign that 
this isn't some minor change.



>
> --
> tomaz
>
>
> On Mon, Aug 18, 2014 at 10:01 AM, Heiko Braun <hbraun at redhat.com
> <mailto:hbraun at redhat.com>> 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
>       * no support for generic complex attributes. these should become
>         (child) resources themselves
>       * 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