On 8/9/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > On 8/9/05, Daniel Perry <[EMAIL PROTECTED]> wrote: > > > >>>-----Original Message----- > >>>From: Craig McClanahan [mailto:[EMAIL PROTECTED] > >>>PS: It's pretty straightforward to build turbo versions of the Struts > >>>HTML tags that have many of the same features described above. But > >>>that doesn't begin to touch the behavior at input time, where the > >>>component itself deals with details like converters, and completely > >>>eliminates the need for a form bean. > >> > >>Now it's funny... i was thinking about this the other day. > >> > >>Why not add to the struts html tags to take validation information? And > >>while you're at it, why not add typing like type="date" or type="int" or > >>type="string" to text fields. > > > > > > Interesting idea. Let's do a bit of mental exploration of what > > actually happens to see how practical it is. When does a Struts > > custom tag actually execute? Only when the page is being rendered, as > > the various HTML elements get produced. Now, when does (server side) > > validation need to happen? On the subsequent form submit (the actual > > call to invoke the server side validator is one of the things that > > RequestProcessor does). > > > > Hmm ..... there's no "tag" there to do the validation for me .... > > maybe I need a component model to encapsulate both the rendering and > > the validating behavior ... wonder where I can find one of those? :-) > > Interestingly, when I read Daniel's post I thought he was advocating adding > validation metadata to the form bean declaration and using dynamic proxies > to generate the beans -- like enhanced Dyna forms. You'd eliminate the need > for a separate validation.xml and, by making the proxy beans smarter so > they could wrap an existing form bean or typed DTO and handle the > string/type conversions in the proxy, you'd get a long way to automating a > lot of the glue code. Sounded like a good idea to me... :-) > > Do your comments change if you look at the idea from that direction?
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. 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. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
