Yes I agree, the framework needs to do a better job at handling ajax events
that create validation errors. As far as I know, there hasn't been much
discussion about actually solving this problem instead of just leaving it up to
everybody.
Anyway, what _we_ did, is basically what you suggested. We implemented
ValidationErrorHandler in our BaseActionBean, and if it's an ajax event (check
if the "X-Requested-With" header is there), then the errors are serialized to
json and sent back using the xjson header; otherwise source page is returned
like normal.
We created this pojo class to contain the full html of the messages at the top
(please fix the following errors: ), and any fields that are in error
public class JsonErrors {
public JsonErrors(String messages,
String[] fieldNames) {
this.messages = messages;
this.fieldNames = fieldNames;
}
private String messages;
private String[] fieldNames;
public String getMessages() {
return messages;
}
public String[] getFieldNames() {
return fieldNames;
}
}
So, if it's an ajax event, the errors are looped over and an instance of this
thing is built. This instance is put into a Map<String, Object> in the
context, getCtx().getJsonMap().put("errors", jsonErrors); Then the X-JSON
header is set to this map as a json string, using net.sf.json.JSONObject for
the serialization.
getResponse().setHeader("X-JSON",
JSONObject.fromObject(jsonMap).toString());
After setting the header, a new StreamingResolution("text/plain", ""); is
returned. That's it server side..
Now client side, we use Prototype 1.6 for ajax requests. One nice thing about
prototype (jquery is pulling me away) is that it automatically takes that
header and puts it into a json variable. So in the ajax request code, we hook
into the onSuccess callbacks globally, and if json.errors is not null, two
things happen: $('errorMessageContainer').update(json.errors.messages) ; and
for each json.errors.fieldNames { $('form')[fieldname].addClassName("error"); }
Any additional code in onsuccess etc is then skipped.
Again not exactly ideal but as of now I haven't seen any radically different or
better approach. I'd like to see stripes tackle this one, but how can it
without making everyone use prototype or some other ajax framework? Maybe a
set of stripes extensions are what is required for the various ajax libraries?
From: Leonard Gestrin [mailto:[email protected]]
Sent: Thursday, April 02, 2009 12:40 PM
To: Stripes Users List
Subject: [Stripes-users] validation errors and ajax/json calls (client expects
JSON back)
Hello,
I am trying to solve the issue where an AJAX request is expecting back JSON
structure as oppose to html snippet and validation errors happen in generic way.
The book's example does not cover such case - it shows case when client expects
valid HTML, thus forwarding to a page containing <s:errors/> works in case of
validation error.
Is there a *nice* way of handling a case when client expects JSON objects but
the form it posts has invalid data? The only way I could think of is converting
ValidationErrors to JSON structure and returning it back to the caller and
caller needs to be smart enough to figure out how to display global/field
validations errors on the page. This sounds a bit clunky, especially on the
front end. Perhaps, something can be done at the client side, where it can
check if the return object is "html" and behave differently (write to a div)
but I am still not sure how it would handle form field specific errors.
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
