On 4/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > Over a year ago Niall submitted a patch (which was not accepted) that > would allow validation using format strings used by the Java Format > classes (such as ###,##0.00). If there's going to be an overhaul of > validation, I would like support for these to be reconsidered. If we > ever go to having an integrated form bean configuration file that > would cover field declaration, formatting/parsing, and validation, > these format strings would avoid requiring the user to specify > different format strings for the same field, like in salary property > in the example on > http://www.rabago.net/struts/formdef/manual.htm#combinedformelement > > Or am I looking too far ahead?
I've always thought that input validation and data conversion are cohesive tasks. Right now, many of the validations convert the data and then throw it away, just so we can convert it again later (this time with feeling!). David W and I tinkered with the idea of keeping the converted data and passing it back, but we didn't have a good place to put it. Now that we are moving to a context-based environment, that might be changing. In my own work, I use two contexts. One is a "sandbox" area where incoming data is validated, converted, and formatted. As it is converted, it moves from the sandbox context to the domain context. On the flip-side, the opposite happens, items are converted/formatted from the domain context to the sandbox context. The View works with the sandbox context (or "FieldState"), the internal commands work with the domain context. Another package that binds validation, conversion, and formatting is FormProc at SourceForge. It uses a similar model where input from an input map is validated and converted to an output map. It's not bidirectional though, and I think being able to roundtrip input is key. And +1 for doing the combined form element in 1.4. Eventually, I'd like to see us take this even farther, so that keys for field labels and hints can also be specified. The goal being to enable us to create a simple utility form from a single JSP tag, using the detail supplied via the XML configuration. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
