Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] named configuration settings
After sending this email, talking to Mike and looking at the configuration code some more I realized
that all i have to create
 
class org.eclipse.higgins.configuration.xml SettingImpl imlements org.eclipse.higgins.configuration.api.ISetting
 
And then to clone ListHandler into SettingListHandler and modify it so instead of directly adding the objectValue
to add the SettingImpl
 
ISetting setting = new SettingImpl(strSettingName, strSettingType, objectValue);
listResult.add(setting);
Now the resulting List is List<ISetting> and i can call getName on each element.
 
And if I bind it to say "htf:settinglist" I am good.
 
George

From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of George Stanchev
Sent: Thursday, November 13, 2008 10:33 AM
To: Higgins (Trust Framework) Project developer discussions
Subject: [higgins-dev] named configuration settings

Hi,
 
I am defining some custom settings in the Configuration.xml and I think it would be nice
thing to be able to retrive the configuration-generated lists and maps (from "htf:list" and
"htf:map") "Name". Currently their corresponding handlers use ArrayList and Hashtable but
there is no way (or at least I dont know how) to retrieve the configuration name.
 
To give example of a use case: I am porting following XML to higgins config:
 
<EntityPolicies>
  <TokenLifetimePolicy>
   <AppliesToSubject></AppliesToSubject>
   ...
   <AppliesToSubject></AppliesToSubject>
  </TokenLifetimePolicy>
  <ClaimsPolicy>
   <AppliesToSubject></AppliesToSubject>
   ...
   <AppliesToSubject></AppliesToSubject>
  </ClaimsPolicy>
</EntityPolicies>
 
The way i have it now is to envelope it in an extra EntityPolicy and then determine the type from
from tge PolicyType setting.
 
<Setting Name="EntityPolicies" Type="htf:list">
  <Setting Name="EntityPolicy" Type="htf:list">
    <Setting Name="PolicyType" Type="xsd:string">TokenLifetimePolicy</Setting>
    <Setting Name="AppliesTo" Type="htf:list">
      <Setting Name="AppliesToSubject" Type="xsd:string"></Setting>
      ...
      <Setting Name="AppliesToSubject" Type="xsd:string"></Setting>
    </Setting>
  </Setting>
  <Setting Name="EntityPolicy" Type="htf:list">
    <Setting Name="PolicyType" Type="xsd:string">ClaimsPolicy</Setting>
    <Setting Name="AppliesTo" Type="htf:list">
      <Setting Name="AppliesToSubject" Type="xsd:string"></Setting>
      ...
      <Setting Name="AppliesToSubject" Type="xsd:string"></Setting>
    </Setting>
  </Setting>
</Setting>
 
But it would be nice to be able to write:
 
<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"
   */
  Object getValue();
}
 
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());
          continue;
       }
    }
  }
  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());
          continue;
       }
    }
  }
}
 
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
 

**********************************************************************

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

**********************************************************************

 

Back to the top