I propose that we branch the current code base to be the code base for
1.3 and any bugfixes thereto, and allow new development to occur on the
head (with bugfixes merged back, of course). Thoughts?
Jason
--
Jason Carreira
Technical Architect, Notiva Corp.
phone: 585.240.2793
fax:
I checked a new validation framework into Xwork this morning that I got
running last night. It's based on some ideas like runtime attributes and
deployment descriptors. What it does (triggered by a
ValidationInterceptor in the interceptor list for an action) is to load
validation xml files for the
How would you handle i18n support, and parametrised messages?
Eg, if you wanted '${0} is an invalid name' as your message
Quoting Jason Carreira [EMAIL PROTECTED]:
I checked a new validation framework into Xwork this morning that I got
running last night. It's based on some ideas like runtime
Jason,
Why are you writing a new validation framework when FormProc has already
gone through these issues? Check out FormProc ( http://formproc.sf.net/
) and let me know if their is something missing which would be necessary
to make it fit WebWork developer needs.
Sincerely,
Anthony Eden
Well, I didn't know it existed, for one :-)
In looking at it, it seems like it does too much. It seems to combine
bean population with validation. I'm also not sure how I feel about the
whole validation with any scripting language and RE's, etc. I actually
really kind of hate things that bundle
Response inline...
Jason Carreira wrote:
Well, I didn't know it existed, for one :-)
No worries...FormProc has been discussed as an option for validation in
WebWork in the past, so I figured that you knew about it.
In looking at it, it seems like it does too much. It seems to combine
bean
FormProc can do as much or as little as you like. If you
only specify a
validator then the values will only be validated. If you want to use
FormProc to do type conversion then you can specify a type converter.
This goes the same for storing the data (in a bean, hash map, etc),
