I guess the obvious solution would be to have private methods that register the factories / IDs internally (e.g. internalRegisterContextFactory), and have public methods that call the internal method AND register the change in the configuration map.
The private internal method is called during configure(), and the public one by users.
So:
public void registerContextFactory(String type, String factoryClassName, ISettingDescriptor factoryDescriptor) {
internalRegisterContextFactory(type, factoryClassName);
// and now also make the change in the configuration map, so it gets persisted when applyUpdates() is called
...
}
private void internalRegisterContextFactory(type, factoryClassName) {
// do here what we do today, i.e. instantiate the CF and register it internally
}
public void configure(...) {
// call internalRegisterContextFactory(), not registerContextFactory()
}
What I don't really like about the bSave parameter is that - if we want to be consistent - this would suggest that every IConfigurableComponent would need that parameter in every method that changes something in the component.
Markus
On Wed, Jul 30, 2008 at 6:41 PM, Greg Byrd
<gbyrd@xxxxxxxx> wrote:
****PLEASE READ THIS***
Just realized that I cc'd the wrong person on my original message. Please don't cc Ravi Iyer on any followups to this thread!
Markus Sabadello wrote:
Hmm ok.
I was just a bit confused by the bSave parameter. I thought if you want to save the configuration, you call applyUpdates(). And if you don't want to save, then you don't call it.
I think the issue is that registerXXX gets called during the initial configuration process, and in those cases, you want (bSave == false), because you're using the information from the configuration map (retrieved from the configuration file), rather than changing it.
Later, if you register something new, you need for that to be added to the map and descriptor, so that you can later save it.
If there's a better way to present this in the API, I think we could be persuaded to change it.
I'll defer to Rajalakshmi for the other questions.
...Greg
Two more questions (just to see if I understand it all correctly):
- The IContextFactory.getContextDescriptor(contextId) method is only used to create a new ISettingDescriptor for a context ID that doesn't exist yet, right? Maybe a better name would be createContextSettingDescriptor(contextId) ?
- Regarding IdASRegistry.registerContextFactory()... What happens to those versions of this method that expect an IContextFactory parameter? They would call getComponentDescriptor() on the IContextFactory to get their ISettingDescriptor, right?
It all looks great to me.
Markus
On Wed, Jul 30, 2008 at 4:04 PM, Greg Byrd <
gbyrd@xxxxxxxx <mailto:
gbyrd@xxxxxxxx>> wrote:
It is the case that the changes are not persisted until
applyUpdates() is called. But how do changes to the in-memory
configuration get made, if not via the registerXXX methods?
...Greg
Markus Sabadello wrote:
So changes to the configuration are now made directly in the
registerXXX methods?
Wasn't the idea that those methods would NOT touch the
configuration, and that you would call applyUpdates instead()
when you want to persist the changes? I liked that better..
Markus
On Tue, Jul 29, 2008 at 5:27 PM, Greg Byrd <
gbyrd@xxxxxxxx
<mailto:
gbyrd@xxxxxxxx>>> wrote:
I've updated the Configuration Management wiki page to
reflect the
proposal for allowing configuration settings (and IdASRegistry
elements, in particular) to be persisted.
http://wiki.eclipse.org/Higgins_Configuration_Management
Section 3 through 5 are the ones to pay close attention to. I
left the "Option 2" text on the page, but we're not currently
pursuing that option.
Please review and discuss on the list, or on the next call.
There
are API changes here that would require modification to multiple
projects.
(Thanks to Rajalakshmi Iyer, who's driving this proposal.)
...Greg
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto:
higgins-dev@xxxxxxxxxxx>
