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