E, too. My guess is that struts was changed
to use status code 400 when validation errors are present. Previously it
must have used status code 200.
I've pushed a change based on Greg's sample and put it in wiki:
https://cwiki.apache.org/confluence/display/WW/AJAX+Validation
Actually
2017-02-16 9:08 GMT+01:00 Greg Huber :
>>I don't understand, 400 is a common way to say that the request was
>>wrong, do you want something else?
>
> On firefox, a 400 triggers the
>
> error: function(xhr, textStatus, errorThrown) {..}
>
> so only displays 'Network or server error!' rather than the
>I don't understand, 400 is a common way to say that the request was
>wrong, do you want something else?
On firefox, a 400 triggers the
error: function(xhr, textStatus, errorThrown) {..}
so only displays 'Network or server error!' rather than the validation
response.
Maybe a 400 on other browse
2017-02-13 11:06 GMT+01:00 Greg Huber :
> Was looking at some client side validation, with the showcase app. I use
> firefox and it was not working, it just returned Network or server error!
>
> https://struts.apache.org/docs/ajax-validation.html
>
> The ajax call was returning 400, so falls back o
Was looking at some client side validation, with the showcase app. I use
firefox and it was not working, it just returned Network or server error!
https://struts.apache.org/docs/ajax-validation.html
The ajax call was returning 400, so falls back onto the error function and
just displays the netwo
Given that DWR integration is broken anyway, and the ajax validation had
mixed content of 2.1 already, I started to draft the documentation for it
here (DWR was there before):
http://cwiki.apache.org/confluence/display/WW/AJAX+Validation
//editing help more than welcomed :)
musachy
On 4/29/07
One of the things I want to do is update the documentation for all the ajax
tags, so we don't have that super-page with everything on it :). I think Don
told me once that the wiki could be branched with the code. If the boxes are
the only way I will just wait until we start building 2.1 to avoid m
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
> is there anyway I can update the docs (wiki)
> without affecting 2.0.8 documentation?
AFAIK this is handled w/ version notations in colorful
boxes so it'll stand out :/ I don't know if there is a
[reasonable] way to support a 2.0 vs. 2.1 docs on a
h
, an ajax request will be made, if
validation succeeds. So now if you are using the ajaxtags to make ajax
requests, ajax validation can be used by setting this attribute to true.
The ajax validation example in showcase is updated with 2 examples, one
using regular submit after validation and another us
t; I have this working, but I want to give it a little more time to
>> >> > anyone to
>> >> > object before committing it :), just to review, these are the
>> >> different
>> >> > validation options:
>> >> >
egular form, regular submit button (normal validation)
>> > 2. css_html form, or xhtml form (validate="true"), regular submit
>> button
>> > (client validation)
>> > 3. css_html form, or xhtml form (validate="true"), ajax submit
bu
1. regular form, regular submit button (normal validation)
> >> > 2. css_html form, or xhtml form (validate="true"), regular submit
> >> button
> >> > (client validation)
> >> > 3. css_html form, or xhtml form (validate="true"), ajax su
> 2. css_html form, or xhtml form (validate="true"), regular submit
>> button
>> > (client validation)
>> > 3. css_html form, or xhtml form (validate="true"), ajax submit button
>> > (client validation)
>> > 4. regular form, css_
form, or xhtml form (validate="true"), regular submit
button
> (client validation)
> 3. css_html form, or xhtml form (validate="true"), ajax submit button
> (client validation)
> 4. regular form, css_html form, or xhtml form, where action has the
> "ajaxVa
e="true"), regular submit button
> (client validation)
> 3. css_html form, or xhtml form (validate="true"), ajax submit button
> (client validation)
> 4. regular form, css_html form, or xhtml form, where action has the
> "ajaxValidation" interceptor, ajax
(validate="true"), ajax submit button
(client validation)
4. regular form, css_html form, or xhtml form, where action has the
"ajaxValidation" interceptor, ajax submit button (validate="true") (ajax
validation = dojo+interceptor, no DWR)
regards
musachy
On 4/21/07, M
lar submit button
(client validation)
3. css_html form, or xhtml form (validate="true"), ajax submit button
(client validation)
4. regular form, css_html form, or xhtml form, where action has the
"ajaxValidation" interceptor, ajax submit button (validate="true") (aj
I'd like to propose a change on the way we do ajax validation. Instead of
using DWR which requires an external dependency and configuring a servlet,
I'd like to have an interceptor in the dojo plugin that extends the
validator interceptor, which outputs JSON with the messages when
if you come up with a
> patch I will check it out.
>
> thanks
> musachy
>
> On 4/13/07, Felipe Rodrigues <[EMAIL PROTECTED]> wrote:
>>
>>
>> I've seen at ShowCase that Ajax validation is broken.
>> Does anyone have more details about that, or
You might want to take a look at form-close.ftl in the Dojo plugin in trunk,
I think there is where the validation is generated, if you come up with a
patch I will check it out.
thanks
musachy
On 4/13/07, Felipe Rodrigues <[EMAIL PROTECTED]> wrote:
I've seen at ShowCase that Ajax
I've seen at ShowCase that Ajax validation is broken.
Does anyone have more details about that, or even how to fix that?
I could work on this issue if I get some direction first.
I also need this kind of validation in a app.
Thanks,
Felipe
--
View this message in context:
21 matches
Mail list logo
