Craig McClanahan wrote:
For validations, using one configuration file versus two isn't really different in terms of functionality being supported -- and in one respect (using different validation rules with the same form under different circumstances) it might actually reduce flexibility. Some will consider it more user friendly, however.
Good point; I tend to tie validation to form beans by form name which eliminates that flexibility anyway but I can see how it may be useful. There are tangible benefits to keeping all the configuration about a given 'foo' as close to 'foo' as possible, but not sufficient to sacrifice functionality.
Handling conversions with smarter proxies seems like it might be more valuable -- although the existing conversion framework supported by BeanUtils isn't really up to the task (it's focused on one way String->Object instead of two way conversions needed for both input and output). But that only gives you the "component-like" capabilities of very simple components. An overall component API does a lot more for you than just eliminate form beans. This is just the characteristic most obvious to someone familiar with Struts.
Yeah, absolutely; I saw this as an incremental enhancement to Struts' functionality rather than as a way to turn Struts into a 'poor man's component framework' ;-) And it's a separate concern to the validation thing above; just an enhancement of the capabilities today's dyna forms offer which could an optional, additional feature.
I guess I should go re-read the Struts Ti thread in case this idea's already in there ;-)
L. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/laurie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
