Exactly my point, you can make the configuration method support a lot of power but only require simple configuration.
Now, multiple config files could possibly confuse users, no doubt about that. I don't think I'd like that. Good thing that configuration is pluggable, so any kind of config is support-able. The main thing, as my main point has always been, is that the internal workins will need to be beefed up. But that's a post-1.3 thing we can discuss more about when the time comes. -Pat > > It's about "scalability", and in this case scaling down to simpler > > projects. > > If it's scaling _down_ you're worried about, surely making as many > elements and attributes as possible optional is the Right Way? The > actions.xml that's part of the source covers enough ground to allow a > newbie to get started (from experience :) and seems to cover most of > the obvious things that a user would like to do. > > An alternative: if each Action has a small config file specifying its > views associated with it (in the same style as Hibernate), and this is > documented in the javadocs for the Action and ActionSupport classes, > then the problem of "not being able to create it" is trivialised. ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
