On Mon, July 25, 2005 1:55 pm, Michael Jouravlev said: > Well, I am not sure that Struts can pick up changes in property file, > though I saw some "Reloadable properties" subproject in Struts > Applications tree.
You can always force the issue... not a good idea, but it can be done. You are correct in general though, it's not something that you can do out-of-the-box. > On the other hand, I think that tying a button textual caption to a > method name like LookupDispatchAction does, is a not right thing to > do. I agree. > Separating events, handlers and captions seems logical for me. I got > used to this when I was programming for Windows. Windows resources > just have an ID, and anyone interested can catch a message from > control with that ID. Button captions are not relevant at all, one can > even change them right in compiled exe file. Again, I agree. These things should be separated as much as possible. All I was saying is that I perfer what binds them to not require me changing code, and a map in a class still counts, even if it's not all that extreme :) > One more note. I am not sure that all config info should be > externalized. It is much easier to have an action and a corresponding > HTML/JSP page(s), than to tie them in a config file. That is, I prefer > Action-page relationship as 1:M, not as M:1 or M:M. Maybe > externalising such relationships works better for you, if you have M:1 > relationship. I am trying to imagine such a use case, and with using > dispatching action, I cannot think of one. I actually do not use any form of DispatchAction most of the time... very rarely will I use anything along those lines. I find it to break the idea of separating responsibilities. I prefer to see a well-named Action for each actual action that can be invoked from a page. Whatever the relationship is, I prefer this. I have some Actions that aren't tied to a particular page at all, some that are very much page-specific, etc. Even when they are only a few lines of code and bloat is not an issue if they are all in the same class, I find it better architecturally for them to be separate. Many people feel differently of course, but that's my perspective on it. > Anyway, there are as many opinions as there are people ;) Absolutely :) > Michael. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
