<Setting Name="EntityPolicies" Type="htf:list">
<Setting Name="TokenLifetimePolicy" Type="htf:list">
<Setting Name="AppliesToSubject"
Type="xsd:string"></Setting>
<Setting Name="AppliesToSubject"
Type="xsd:string"></Setting>
...
</Setting>
<Setting
Name="ClaimsPolicy" Type="htf:list">
<Setting
Name="AppliesToSubject" Type="xsd:string"></Setting>
<Setting Name="AppliesToSubject"
Type="xsd:string"></Setting>
...
</Setting>
</Setting>
This way no extra element for explicitly specifying the
substructure's type will be needed - the
type can be deducte by the configuration
object name.
So to solve this, we can create IHigginsConfigurationObject interface that will define
String getName()
and possibly String getType() methods.
Then we need to create wrapper classes for the returned classes.
It is a little bit of a hastle but then we
can have lists and maps that know their own names and the
configuration consumers can be more flexible in consuming
the configuration. The drawback is that these
delegator objects need to be supported.
A simplier design (but it will break current model) would
be the return type from getSetting() to always be
IHigginsConfigurationObject. Then it can be
defined as:
interface IHigginsConfigurationObject {
/**
* Returns the setting name <Setting Name="myname"
Type="xsd:string"/> --> "myname"
*/
String getName();
/**
* Returns the
setting type <Setting Name="myname" Type="xsd:string"/> -->
"xsd:string"
*/
String
getType();
/**
* Returns the
setting underlying value class <Setting Name="myname"
Type="xsd:string"/> --> "xsd:string"
}
So then one iterate configuration:
<Setting Name="Policies" Type="htf:list">
<Setting Name="PolicyType1"
Type="htf:list">
<Setting Name="Setting1"
Type="xsd:string">blah1</Setting>
<Setting Name="Setting1"
Type="xsd:string">blah2</Setting>
<Setting Name="Setting2"
Type="xsd:string">blah1</Setting>
<Setting Name="Setting2"
Type="xsd:string">blah2</Setting>
</Setting>
<Setting Name="PolicyType2"
Type="htf:list">
<Setting Name="SettingA"
Type="xsd:string">mlahA</Setting>
<Setting Name="SettingA"
Type="xsd:string">mlahB</Setting>
<Setting Name="SettingB"
Type="xsd:string">mlahA</Setting>
<Setting Name="SettingB"
Type="xsd:string">mlahB</Setting>
</Setting>
</Setting>
via this code
PolicyType1 policyType1 = new PolicyType1();
PolicyType2 policyType2 = new PolicyType2();
for
(List policy : configPoliciesList) {
if (policy.getName.equals("PolicyType1")) {
for (Object policySetting : policy)
{
if ((policySetting.getValue()
instanceof String) && (policySetting.getName="Setting1"))
{
policyType1.addSetting1((String) policySetting.getValue());
continue;
}
if ((policySetting.getValue()
instanceof String) && (policySetting.getName="Setting2"))
{
policyType1.addSetting2((String) policySetting.getValue());
}
}
if (policy.getName.equals("PolicyType2")) {
for (Object policySetting : policy)
{
if ((policySetting.getValue()
instanceof String) && (policySetting.getName="SettingA"))
{
policyType1.addSetting1((String) policySetting.getValue());
continue;
}
if ((policySetting.getValue()
instanceof String) && (policySetting.getName="SettingB"))
{
policyType1.addSetting2((String) policySetting.getValue());
}
}
}
And a comporomise would be to keep current and
introduce
additional "named" setttings:
htf:named_list
htf:named_string
htf:named_map
...
Which I can contribute
Thoughts?
George