Representation of boolean attribute in our XML configuration

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Representation of boolean attribute in our XML configuration

Jeff Mesnil
Out of curiosity, have we made a decision about the XML representation of boolean attributes in the next-generation of our management API?

At the moment, we have 3 different styles:

1. as a empty element <expose-resolved-model/>
2. as an attribute <append value="true”/>
3. as an element text child <backup>true</backup>

What’d be the default style in the next version?
That’s more a question for Tomaz but he’s in PTO :)

jeff


--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Representation of boolean attribute in our XML configuration

Brian Stansberry
On 8/29/14, 7:34 AM, Jeff Mesnil wrote:
> Out of curiosity, have we made a decision about the XML representation of boolean attributes in the next-generation of our management API?
>
> At the moment, we have 3 different styles:
>
> 1. as a empty element <expose-resolved-model/>

Not this. This cannot support an expression.

> 2. as an attribute <append value="true”/>
> 3. as an element text child <backup>true</backup>
>
> What’d be the default style in the next version?
> That’s more a question for Tomaz but he’s in PTO :)
>

Default is to not use an element for a single attribute. Include
expose-resolved-model="true" in some element that represents more than
that, i.e. the resource.

The scenario where this gets ugly is resources that have a ton of
attributes, resulting in unwieldy xml. For example, the hornetq server
resource. ;)

The admin console UI faces a similar problem with those kinds of
resources. To help we are going to add a 'grouping' field to the
attribute description metadata to provide a hint to the console as to
how to present logically related attributes. I don't see why our
standard xml parsing / marshalling couldn't use the same information to
create an xml element per attribute group.

> jeff
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev