[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] proposed changes to Configuration and IdASRegistry
|
Hello,
I agree on the following points:
Private register methods can be called during configure() and public
register methods can call the private register method as well as update
the global map.
We could change the name of IContextFactory's
getSettingDescriptor(String contextId) method to
createSettingDescriptor(String contextId) method, since it only used to
creates a new setting descriptor.
To clarify about the IdASRegistry's registerContextFactory(IContextFactory
factory) method, all the variants of registerContextFactory() method
eventually call the registerContextFactory(IContextFactory factory) method.
So, the actual update to the global map will occur only in the
registerContextFactory(IContextFactory factory) method, and you are right,
it will in turn call the factory's getComponentDescriptor() method to get
the ISettingDescriptor for that factory component. We need to pass the
factoryDescriptor to the registerContextFactory(String[] types, String
factoryClassName, ISettingDescriptor factoryDescriptor) method, so that the
IContextFactory object can be instantiated with the supplied
ISettingDescriptor.
Thanks,
Best regards,
Rajalakshmi Iyer
From: "Markus Sabadello" <msabadello@xxxxxxxxxxxxx>
To: "Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
Date: 07/30/2008 11:20 PM
Subject: Re: [higgins-dev] proposed changes to Configuration and IdASRegistry
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> <mailto: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>
<mailto:higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/higgins-dev
------------------------------------------------------------------------
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto: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
_______________________________________________
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
