> -----Original Message----- > From: Rickard Öberg [mailto:[EMAIL PROTECTED] > > Ah, ok, I looked at the interface you sent in email, and true, it > doesn't describe it well. But, I would argue that the > interface should > be split, as I described in my first email on programmatic > configuration. > > You'd typically have 3 players involved: > 1 Some configuration repository which the application can use to get > configuration settings.
This is the RuntimeConfiguration Interface. Both this and ProgrammableConfiguration are implemented by ConfigurationManager right now. This uses a very flat data structure. You call getActionConfig(String namespace, String name) to get an ActionConfig. The Package structures, etc. are stripped away as they're only used to provide defaults and inheritance. > 2 Some configuration bundle containing settings that have > been loaded. > This mostly just have get/set methods. This is ProgrammableConfiguration. It also has a reload() method to tell it to get the new configuration from 3, below, and buildRuntimeConfiguration(), which can be thought of as a "save" method which tells it to generate the runtime configuration from the hierarchical configuration structures which can be programmatically tweaked. > 3 Various loaders which read configuration files (e.g. XML) > and create > configuration bundles and register these with the repository. This is ConfigurationFactory, which can have one object implementing Configuration registered with it (by default this is DefaultConfiguration). When ConfigurationManager.reload() is called, it calls ConfigurationFactory.getConfiguration().init(this) to tell the Configuration to load its configuration and register the configuration params with the ProgrammableConfiguration it's passed (ConfigurationManager). DefaultConfiguration starts at init() and loads the xwork.xml file, parsing through it building up data structures and registering them with the ProgrammableConfiguration it is passed. I'm thinking the Configuration Interface should be renamed to ConfigurationProvider and ConfigurationFactory could be ConfigurationProviderFactory. > > It then becomes possible to configure the app at runtime > without using 3 > at all, since 2 can be created programmatically. Instances of > 2 can also > be serialized and sent around in a system without much trouble. > Hadn't thought of sending serialized configuration objects around. Why would you want to do this? Right now what happens is that ConfigurationManager has a static instance which is initialized at class initialization and calls reload to get the Configuration from the ConfigurationFactory. > It seems the current interface does 2 and 3. Split it up into > ConfigurationLoader and ConfigurationBundle and it should work better. > > This is basically what's there. Jason ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
