|
I guess it goes without saying that if IConfigurableComponent.getComponentSetting() can return a Map (which in turn contains sub-elements that will be modified) then the IConfigurableComponent needs to make sure it can sense modifications to that Map.
For the time being, I added these very simple methods to IContext:
/**
* Used to update one setting element for this context. Oftentimes, an instance
* of IContext is also an {@link IConfigurableComponent}. In this case, the new
* setting will typically be set (or reset) in the component's settings {@link Map}
* @param key setting name
* @param value setting value
* @param failUnsupported Default false. When true, the operation will fail with
* {@link NotImplementedException) if the context does not support settings of this type.
* When true, if the context does not support settings of this type, the setting will be
* ignored by the context.
* @throws IdASException
*/
public void setComponentSetting(String key, Object value, boolean failUnsupported) throws IdASException;
/**
* @see setComponentSetting(String, Object, boolean)
*/
public void setComponentSetting(String key, Object value) throws IdASException;
If/when we iron out a nice solution for IConfigurableComponent, I'll switch over to that.
>>> Greg Byrd <gbyrd@xxxxxxxx> 06/25/08 11:38 AM >>>
For the second option (IConfigurableComponent.setComponentSetting), I assume
this would replace a component setting that was already there. So we'd need
a getComponentSetting() for the case in which you just want to change an element
of a setting(e.g., add new element to list or map, remove element from list/map).
IMO, this would only affect the instance of the component being modified.
And, of course, this might trigger other actions in the general case,
essentially a re-configuration of the component. For some components, the
setComponentSetting method could be quite complex, as the action could depend on
the particular setting being modified.
...Greg
Jim Sermersheim wrote:
>
>
> both good points that I have no comeback for.
>
>
> Ok, so let's go back to choosing between these:
>
>
> IContext.setComponentSetting(String name, Object value);
> IConfigurableComponent.setComponentSetting(String name, Object value);
>
>
> For now, I'll do the former and if Mike or someone wants to talk about
> the latter, we can switch over later.
>
>
> Jim
>
>
>
>
>
> >>> "Duane Buss" <dbuss@xxxxxxxxxx> 06/25/08 10:54 AM >>>
>
> Two Issues
>
> * How do I know if the context attribute is temporary or permanent,
> and is this a per instance attribute or a global setting that other
> instances of this same context will pickup.
>
>
> * Doesn't this create confusion between config settings and context
> properties? How many items in config would also be settable via
> setProperties?
>
>
>
> Duane
>
> >>>
>
> *From: *
>
>
>
> "Jim Sermersheim" <jimse@xxxxxxxxxx>
>
> *To:*
>
>
>
> Higgins dev <higgins-dev@xxxxxxxxxxx>
>
> *Date: *
>
>
>
> 06/25/08 10:36 AM
>
> *Subject: *
>
>
>
> [higgins-dev] Dynamic setting updates for IContexts
>
> Over the past month, we've had a number of requests to be able to
> programatically update different settings for an instance of
> IContext. The use cases typically are for things where we need the
> context provider to behave differently based on changing conditions.
>
>
> At first, we started thinking we should piggyback the existing
> IConfigurableComponent interfaces. Currently IContext does not extend
> IConfigurableComponent, but we could change that. Two problems exist
> with doing it this way:
>
> * There's no way to update a single/specific setting. It would be
> cumbersome or even break things to send in an entire new configuration
> Map each time we want to change a single setting
>
> * Often the component settings are shared among other components. The
> ability to update that shared Map may cause other problems.
>
>
> So next, we started thinking we need a simple way to update IContext
> instance-specific settings. The idea was to add something like
> IContext.setProperty(String propName, Object propVal); One could call
> it like this:
>
> myContext.setProperty("UseSSL", "true");
>
>
> There are some questions like: What if the CP doesn't support the
> "UseSSL" setting? Should it fail the call to setProperty? How does the
> caller discover ahead of time whether a CP supports a setting?
>
>
> I started looking at that and thought, wait a minute, IContexts *already
> have* properties. They're called attributes. All a cp needs to do is
> we need is to define special attribute identifiers which are valid to be
> placed on their context, and have a defined semantic behavior. So one
> could make the same setting call like this:
>
> myContext.addAttribute(new
> BasicAttribute("http://example.com/ontology/contextSettings#UseSSL",
> "true"));
>
>
> The benefits are that we introduce no new APIs, and the caller can
> discover whether the context's model allows specific settings
>
>
> Jim
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
| 