> -----Original Message-----
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 3:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Programmatic configuration
>
>
> Jason Carreira wrote:
> >> Why is an interface needed here? I thought this was just a
> singleton
> >> thingy which the app can query. Are there several implementation
> >> possibilities, and if so, why?
> >
> > Probably not needed. I just created them to keep me sane.
>
> Ok. Then I'd propose that it's removed. :-) Let's keep
> simple things simple. Sometimes you want flexibility and
> strategy possibilities, and
> sometimes you want rigidity and stability. This is a case of
> the latter
> I think.
Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was ProgrammableConfiguration) - this
is just ConfigurationManager
2) Make RuntimeConfiguration into a class and move that part of ConfigurationManager
over to it
There will always be only one RuntimeConfiguration which is created by
ConfigurationManager from the configuration structures it holds which are initialized
by the ConfigurationProviders
> >
> > But you want to give the API users one thing to interact with, that
> > being the ConfigurationManager. It's already got to know
> how to build
> > the runtime configuration from the programmatic configuration.
>
> Can't this be done when a configuration bundle is registered with the
> ConfigurationManager? Or, lazily upon access? Should work
> just fine as
> far as I can tell.
The problem here is the case of programmatic configuration. If someone writes code to
call into the ConfigurationManager to change the configs, then they need to be able to
generate the runtime configuration from it.
>
> >> That's backwards. It should be possible to have N implementations,
> >> one for each kind of configuration, simultaneously. Remember, an
> >> application may be created by merging several subapps, and each
> >> subapp may have its own way to read configuration. The
> total app must
> >> be able to handle this. With only One way to read
> configuration that
> >> is not possible.
> >
> > That's a good point. We'll take it up with Patrick... I'll
> plead his
> > starting that. :-)
>
> In general, this "app created from subapps" is something that
> needs to
> be considered in all aspects. WebWork was monolithic in this
> sense, and
> it'd be good if we can move away from that. As I've already noted a
> couple of times, I think in the future it will be more common
> to build
> webapps from smaller webapps, e.g. through portlets.
I agree. How would the sub-apps configuration get loaded? How are they packaged?
>
> >> This is backwards, because how would you know when to call
> >> reload()? The only entity which can know this are the individual
> >> ConfigurationFactories.
> >
> > Okay. We can look at how this should be implemented. I
> still think the
> > user needs to be able to trigger this programmatically,
> though, like a
> > "refresh my config".
>
> Ok, how about this then: have the configuration loaders be able to
> register with the configuration API, and on "refresh" simply
> give them a
> callback. That way the bundles (which should be *stupid*) does not
> contain logic that understand "refreshing". Then, any loaders
> that can
> reload can remove the previous configuration and add a new one.
This is what it does now. Here's the reload() method on ConfigurationManager:
public synchronized void reload() throws ConfigurationException {
packageContexts.clear();
ConfigurationProvider config = ConfigurationProviderFactory.getConfig();
config.init(this);
buildRuntimeConfiguration();
}
This, in order, clears the current data structure, gets the ConfigurationProvider
(which could be changed to a List of ConfigurationProviders) and tells it (them) to
init, passing it this so that they can call back to the ConfigurationManager to
register configurations, then it builds the runtime configuration from the registered
configurations.
>
> > I see your points, but I still think there are some details to be
> > worked out. Check out the code and let me know how you
> think it should
> > change.
>
> There's always details to work out :-) I'll check it out.
>
> /Rickard
>
Jason
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
