Dependent values and linking
Ian Springer
ian.springer at redhat.com
Fri Jun 17 22:43:23 UTC 2011
Heiko,
Sorry I missed the meeting. Here are my comments:
1) It seems unfortunate to not take advantage of cached configdefs for
the 95% of configdefs that don't contain any props with dynamic options.
Couldn't a utility method be written to determine if a configdef
contains any dynamic option props? eg:
public static boolean
containsDynamicOptionProperties(ConfigurationDefinition configdef) {
for ( ... ) // recursively iterate propdefs
if (simplePropdef.getOptionSource() != null) {
return true;
}
}
return false;
}
The GUI config editor would call this method on each configdef and only
request a dynamic configdef from the Server if the method returns true.
An optional optimization would be to cache the results of calls to
containsDynamicOptionProperties(), either in a Map<Integer, Boolean> or
in a transient boolean field on the configdef itself. However, I think
executing this method every time will still be significantly faster than
always making the server-side call, which, besides the RPC overhead,
will end up having to run similar code on the server side to scan the
configdef for propdefs with option sources.
2) As for the best place to call getOptionValuesForConfigDefinition() in
coregui, I think the view, and not the config editor, should be
responsible for retrieving the configdef, with dynamic options retrieved
if appropriate. ConfigurationEditor currently has two constructors - one
that requires the caller to pass in both the Configuration and
ConfigurationDefinition, and another that only specifies a config type
and a resource id and places the responsibility on the config editor to
lookup the config and configdef. The latter constructor is only used in
one place (plugin config view iirc); I think we should get rid of it and
require callers to always be responsible for looking up and passing in
the config and configdef. So the pseudo code in the a particular config
editing view would be:
// lookup config and config def (possibly cached) and onSuccess of both
lookups run the remaining code
if (ConfigUtility.containsDynamicOptionProperties(configdef)) {
configdef =
configService.getOptionValuesForConfigDefinition(configDef.getId())
// onSuccess of this call run the remaining code
} else {
// run the remaining code
}
ConfigurationEditor configEditor = new ConfigurationEditor(config,
configdef);
addMember(configEditor);
3) I would use EnumeratedValueSource, rather than OptionSource, as the
name in PropertyDefinitionSimple, for consistency with the existing
field/method names
4) For quite while, we've wanted to add support for another type of
dynamic options - option values returned programmatically by an Agent
plugin. I know this isn't needed for Heiko's as7 plugin use cases, but
let's think ahead and design how we would do it and make sure it lives
happily with the server-side expression-based dynamic options. To
clarify, I am suggesting design it now, not implement it now.
I think the agent plugin dynamic options may be as simple as a new
"dynamicEnumeratedValues" boolean field on PropertyDefinitionSimple,
where the plugin descriptor syntax would look something like:
<c:simple-property name="foo" dynamicOptions="true" />
or possibly:
<c:simple-property name="foo">
<c:property-options dynamic="true" />
</c:simple-property>
On the server side, I think we could still just have the one
getOptionValuesForConfigDefinition() method, and update it to understand
how to retrieve both types of dynamic options (for agent plugin dynamic
options, it would make a call out to the Agent to ask the plugin for the
option values). We would just need whether we'd want to allow a
particular simple propdef to support both types of dynamic options, or
only allow one or the other (I am thinking the latter).
-- Ian
On 06/14/2011 12:00 PM, Heiko W.Rupp wrote:
> Meeting notes are available here:
>
> Minutes: http://people.redhat.com/~manderse/irc.freenode.org/meetings/rhq/2011/rhq.2011-06-14-15.02.html
> Minutes (text):http://people.redhat.com/~manderse/irc.freenode.org/meetings/rhq/2011/rhq.2011-06-14-15.02.txt
> Log: http://people.redhat.com/~manderse/irc.freenode.org/meetings/rhq/2011/rhq.2011-06-14-15.02.log.html
>
> Thanks
> Heiko
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com
More information about the rhq-devel
mailing list