> That would actually > fulfill the goals I had. Would you find that difficult to manage?
No, surely not :-) I we were misunderstanding each other; actually you wrote " I'm not sure about introducing a whole new collection of objects, and management components to go along with it." And I just replied, that I wouldn't like it either, but ist also unnecessary with my approach. However, I think we are d'accord here, and your config file extensions wouldn't add any managing effort, so they would be ok for me. > > The one thing your suggestion has over this is the dynamic > nature of the configuration. That would be nice indeed :) > However, since Struts configuration information is frozen > anyway, I'm not sure it would be a big deal. The struts configuration is frozen indeed (even I know some guys who reload it in running webapp, to take advantage of resin's class-reloading features during development), but the underlying ressources aren't. If I have to populate a drop-down or something, ok, I probably have no need to change it. I give you another example, we have 4 different payment providers, we are working with. Sometimes they have maintenance, sometime they are just buggy, however, it happens twice a month, that i need to take one of them from the page. All I do is edit the configuration for payment and one minute later it disappears. I think there are more useful examples for reloading config thinkable. > > This would just be added to ActionMapping, so it's a fairly > simple and straight-forward change. Then just a modification > of RequestProcessor and we should be all set. This is true, it would fit into the current flow, as far as I know it. > init() method. This would allow them to maybe get all the > data they would need at the start, instead of having to do it > with each call to a setup method. So, just like Actions, > they would be shared. The down-side to this is that, like > Actions again, they would have to be thread-safe. People > might be tempted to call init() themselves to update the > data, but that would be a Bad Thing(tm). I think "people" shouldn't have a chance to get to the "setup objects". They would be instantiated by the "instantiator" only, be it request processor, or what ever. If "people" instantiate them later, they would be context-less, already used, and do no harm (pick one:-)) > What do you think of this approach? I realize it doesn't > have all the benefits of your idea, but I frankly think it > would be easier to potentially get some traction with as far > as getting added to Struts goes simply because it's not that > big a change to Struts itself, not that big an addition. > But, I think it would open up a world of flexibility for > people. Thoughts? :) Actually I think both approaches could be well combined too. Your idea has the benefit of actually knowing which action uses which configuration. Since the people who develop an application and people who deploy it aren't always the same, having one place to look is a manageability advantage. What I actually don't like, is having setup classes. I think it's a bit too powerful for a simple action, and it looks ugly :-) The combination could be, that there is a ConfigurableAction you can extend, which communicates with the configuration framework, so you don't need to do it yourself, which gets it's configuration "name" from the mappings and provides some methods which a) can be overwritten do to the not-that-trivial-stuff b) are able to do the "standard" stuff theirself, like instantiating something and put it in the application scope. What do you think? Regards Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
