Hi,
I am trying to use the struts validation xml and testing with my action but
its not working in struts 2.1.6 .
Same code working fine in struts 2.0.6
Any issue in the 2.1.6 version ? Are we need to include any interceptor ?
I pasted below my codes.Any one had same issue previously ?
Neither Commons Validator nor Struts knows how to process XML requests
like that out of the box. Assuming Struts 1, the answer is that you will
have to write your own logic to populate the form bean from the XML
request, after which validation can be performed the same as you would
with a regul
It's a question regarding commons validator api, wherein i am trying to
validate an input request form (xml-request) which contains a collection
of
items...like
222
04/04/2004
223
04/04/2004
What would be the valid format for the commons-validator form to
valid
Thanks Ted! I felt a little queezy about using "requiredstring" but
couldn't get Eclipse to reveal a list of valid atrribute values with code
assist.
On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> what about simple type conversion?
On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
what about simple type conversion? How will you ever have non-string
coming from html? Does this mean we are back to domain object with
only strings?
No, it means that we have a special validator for Strings to cover
both the notion of be
--- [EMAIL PROTECTED] wrote:
> what about simple type conversion? How will you ever
> have non-string coming from html? Does this mean we
> are back to domain object with only strings?
S2 (and others) already do simple type conversion.
You will "never" have non-strings coming from the
*browser*
what about simple type conversion? How will you ever have non-string
coming from html? Does this mean we are back to domain object with
only strings?
On 3/23/07, Dave Newton <[EMAIL PROTECTED]> wrote:
--- [EMAIL PROTECTED] wrote:
> Are you suggesting that we *ARE* back to needing
> *DUMB* string
--- [EMAIL PROTECTED] wrote:
> Are you suggesting that we *ARE* back to needing
> *DUMB* strings in our *RICH* domain models? I
> thought the tired old FormBean was a thing of the
> past!
That's backwards. You were testing an int with a
String test and it failed *because* it wasn't viewing
every
There's a different validator for numeric types.
* http://struts.apache.org/2.x/docs/required-validator.html
On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Oh! It is an int.
-
To unsubscribe, e-mail: [EMAIL PROTEC
Are you suggesting that we *ARE* back to needing *DUMB* strings in our
*RICH* domain models? I thought the tired old FormBean was a thing of the
past!
On 3/23/07, Dave Newton <[EMAIL PROTECTED]> wrote:
--- [EMAIL PROTECTED] wrote:
> Oh! It is an int.
That could cause a problem :)
Probably n
--- [EMAIL PROTECTED] wrote:
> Oh! It is an int.
That could cause a problem :)
Probably not a good idea anyway, since you may want to
enforce either Zip or Zip+4 and not let people enter
"145".
d.
8:00? 8:
Oh! It is an int.
Scott
On 3/23/07, Dave Newton <[EMAIL PROTECTED]> wrote:
--- [EMAIL PROTECTED] wrote:
> What do you mean by target type?
What (Java) type is the value you are validating?
>
> On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> > Is the target type a String?
> >
> > On
--- [EMAIL PROTECTED] wrote:
> What do you mean by target type?
What (Java) type is the value you are validating?
>
> On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> > Is the target type a String?
> >
> > On 3/23/07, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > > Actually, I remove
What do you mean by target type?
On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
Is the target type a String?
On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Actually, I removed the js attributes and it behaved the same.
---
Is the target type a String?
On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Actually, I removed the js attributes and it behaved the same.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Actually, I removed the js attributes and it behaved the same.
On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
What happens if the custom JavaScripts are not used, but the
validation element is used?
If the JavaScript seems to be culprit, then I'd use FireBug or
something to watch the reques
What happens if the custom JavaScripts are not used, but the
validation element is used?
If the JavaScript seems to be culprit, then I'd use FireBug or
something to watch the request, to see if there is something funky
going on there. The server-side can only handle what it receives.
-Ted.
On 3
Server side.
On 3/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
Is it the server-side or client-side validation that is firing when it
should not?
If it is the client-side, and the custom scripts are based on
Prototype, there could be DOM-related issues, since Prototype rewrites
the DOM.
-Ted.
Is it the server-side or client-side validation that is firing when it
should not?
If it is the client-side, and the custom scripts are based on
Prototype, there could be DOM-related issues, since Prototype rewrites
the DOM.
-Ted.
On 3/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I have
I have this field on a web page:
and this validator configured for it:
The only way I can pass the "Zip Code is required" validation is to remove the
validator entry. All the other fields on the page work
fine with their validators. Is there some issue wi
On 7/19/06, harriquitawn tawn tawn <[EMAIL PROTECTED]> wrote:
I have configured 2 struts-config.xml files (struts-config1.xml and
struts-config2.xml), two validation.xml files (validation1.xml and
validation2.xml), one validator-rules.xml and the web.xml file.
...
When I execute it, I obtain th
I have configured 2 struts-config.xml files (struts-config1.xml and
struts-config2.xml), two validation.xml files (validation1.xml and
validation2.xml), one validator-rules.xml and the web.xml file.
Web xml file:
...
/WEB-INF/struts-config1.xml,/WEB-INF/struts-config2.xml
...
In struts-config1
22 matches
Mail list logo