Leo Sutic wrote: > I've done some experimentation with persisting a component's > configuration. <snip/>
I vaguely recall solving something like this (and context persistence and even dependency persistence (before we something like metadata was formalized)) using a listener-style approach. With phoenix 3.0 alpha 3, or somethin'. A stored procedure triggered a configuration change which some set of kernel services merged with the config stored for the component, then reloaded the whole block gracefully. Hmm.....
Have you tried anything like that? IMHO components should not change their configuration, by contract. If the configuration is changed by an external party, its nicest if you can just reload the component with the new config. Of course, that requires that you can make the container aware of the third party that wants to make the changes.
What about a lifecycle extension and/or a callback mechanism? Tried any of those?
I understand those may be a little more complex than a mutable configuration object, but like I said, I'm a bit weary of the concept of components being in control of their own configuration. It breaks IoC, and sounds like it could break security too.
> interface Persistable {
> Configuration getConfiguration ();
> }
>
> but then I came upon the little snag that the container may want to
> add more configuration information to the Configuration before it is
> stored.so why doesn't the container use the provided configuration as a base? In code:
componentProvidedConfig = persistable.getConfiguration(); checkComponentProvidedConfigIsValid( componentProvidedConfig ); finalConfig = ConfigurationUtil.merge( componentProvidedConfig, customContainerConfig ); persistComponent( persistable, finalConfig, otherStuff )
man, this feels like deja vu. I'm sure we talked about it before...
<snip/> > But that's quite ugly.
agreed.
> What do you think?
I'd like to see the case made that alternative methods really don't work before we put it in framework...
...If we do put it in it should be made clear that components SHOULD NOT ever attempt to cast the configuration past in through Configurable into a MutableConfiguration as they MAY NOT modify that configuration.
(the main concern I have is in fact that Joe User may think that components modifying their own config is a good idea in general; and I don't think that's the case)
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
