On Sep 12, 2016, at 7:44 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
On 6 Sep 2016, at 15:10, Brian Stansberry wrote:
> It’s not an uncommon thing to have a management attribute A that is required; i.e.
must be set, but also has an alternative attribute B, where setting B satisfies the
requirement for A, making an undefined value for A legal.
Would this also include cases where e.g. a logger has an
attribute 'mode' which could be one of file, console, rsyslog
and then dependent attributes that are only usable with
one of the modes. Something like filename for 'file',
none for 'console' and 'remote-socket-binding' for 'rsyslog' ?
Both 'filename' and 'remote-socket-binding' would be
required only for their mode (and even forbidden otherwise).
No, that kind of thing is not covered by this work. We have ‘requires’ metadata for an
attribute that names other attributes that must be set if the given attribute is set, but
that’s just a relationship based on defined vs undefined, not on any particular defined
value. There would need to be some sort of new metadata added to cover what you describe.
Perhaps something like
“requires-if => [
{
“value” => true,
“attributes” => [“another”, “athird”]
},
{
“value” => false,
“attributes” => [“afourth”, “afifth”]
},
]
Note that for something like that we couldn’t support it for attributes that allow
expressions, as the validation of the constraint would need to happen before we’re able to
accurately resolve expressions. But for enum attributes like your example I don’t think
that would be an issue. I don’t imagine using an expression to control an enum would be a
typical thing.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat