Hi John-
Thanks for your excellent suggestions, I did end up coding a solution
similar to your example. I appreciated learning about the event status, I
missed that on the documentation and it proved to be useful.
I assure you that the e-mails are not being used for spam! Well.... OK,
maybe it is, but it's for internal employees who signed up for a company
benefit, so Stripes is being used for the powers of good! Or at least mild
benevolence.
I learned a bit more about Stripes error validations, especially the fact
that all the validations take place even before your getters are set, so
that explained why my incoming arrays from the webpage were purged of bad
values when I tried to access them in my code.
I realize that I'm kind of going against the Stripes model of error
handling, which I understand to be summarized as "capture all the bad
values, dump them into a <s:error> block in your JSP". Perfectly reasonable,
but I needed a bit more finer control to highlight a specific row in an
arbitrary length list of entry fields in the JSP. Maybe I can do this
already, but I'm pretty much still a neophyte at this point.
Anyway, just for anyone else who might be interested below is my code that I
came up to handle my errors. It builds up a JSON object, which my AJAX
application understands and processes the error information, obnoxiously
making the incorrect fields bright red, etc. I create a single
"simpleError()" on the ValidationErrors object to trigger the redirection of
handleValidationErrors, as I'm relying on my own JSON object to pass on the
error data.
The ValidateEmails... functions are pretty much a duplicate of the Stripes
validations, with the single exception that it provides index data, such as
the 5th, 9th, 10th field positions being in error, etc. I would love to have
the @Validate methods just provide the index of where the error occurred on
the List<> - I will personally name my children "Stripes Williams" and
"Stripes Williams II" for this feature!
Even without this dream feature, just having the error checking taking place
before the event handler kicked in made going this route completely
worthwhile. A typical ActionBean can have as many as a dozen Event Handlers,
and not having to put in error checking code in every one of them really
paid off handsomely through clean(er) code.
private JSONObject returnErrors;
private List<String> benefit_email;
private List <String> benefit_activitynote_contact_date;
private List <String> benefit_activitynote_followup_date;
private List <String> benefit_phone_num;
private List <String> benefit_phone_ext;
@ValidationMethod()
public void validateEnrollees(ValidationErrors errors){
returnErrors = new JSONObject();
try{
ValidateEmails.validate(benefit_email,
"benefit_email_error",
returnErrors);
ValidateDates.validate(benefit_activitynote_contact_date,
"benefit_activitynote_contact_date_error", returnErrors);
ValidateDates.validate(benefit_activitynote_followup_date,
"benefit_activitynote_followup_date_error", returnErrors);
ValidatePhoneNumbers.validate(benefit_phone_num,"benefit_phone_error",returnErrors);
ValidatePhoneExtensions.validate(benefit_phone_ext,"benefit_ext_error",returnErrors);
if(returnErrors.length()!=0){
errors.add("BOErrors", new
SimpleError("BoError",(Object [])null));
}
}catch(JSONException jex){
jex.printStackTrace();
}
}
@Override
public Resolution handleValidationErrors(ValidationErrors errors) throws
Exception {
if(errors.isEmpty()){
return null; //No errors? Onward to
event handler.
}
//pass on JSON object for AJAX handling
return new
StreamingResolution("text/html",returnErrors.toString());
}
Newman, John W wrote:
>
> There's probably a few different ways to do it, but you can always fall
> back to a custom validation method,
>
> @ValidationMethod(when=ValidationState.ALWAYS, on={"event1", "event2"})
> public void validateEmails() {
> if (lotsofemail != null) {
> for (int i = 0, n = lotsofemail.size(); i <n; ++i) {
> String email = lotsofemail.get(i);
> boolean isValid = emailTypeConverter.convert(email);
> if (isValid) {
>
> } else {
> invalidIndexes.add(i);
> invalidEmails.add(email); // maybe put these
> in somewhere else so they can easily correct and resubmit
> }
> }
> }
> }
>
> Something like that, but there still might be a way to do it sticking with
> the annotations, idk. I hope you're not amassing email addresses to spam
> people. `_ยด
>
>
> -----Original Message-----
> From: Derrick Williams [mailto:a...@derrickwilliams.com]
> Sent: Monday, January 17, 2011 10:03 PM
> To: stripes-users@lists.sourceforge.net
> Subject: [Stripes-users] Getting Array Index with Stripes Validations?
>
>
> I've begun using the Stripes @Validation feature and it's been fantastic.
> It's a lifesaver when Stripes intercepts all the multitudes of input
> errors and shunts it to my instance of handlesValidationErrors(), using
> the ValidationErrorHandler interface.
> My EventHandler doesn't even get called. It's like it was never submitted.
> It saved me a lot of work. Priceless!
>
> Life would be perfect in every way with Stripes Validations except for
> this one application I'm working on, which for boring reasons needs to
> handle errors the same way it did before I converted it to Stripes. I'll
> describe what I'm trying to do, and no doubt there's an infinitely better
> way to do it.
>
> The application has a list of e-mails coming in, being checked by Stripes
> Validation:
>
> @Validate(converter=EmailTypeConverter.class)
> private List<String> lotsofemail;
>
>
> Our users work their fingers to the bone all day long typing in long lists
> of e-mail. Invariably they mistype one. No problem,
> handleValidationErrors() has this under control, right?
>
>
> @Override
> public Resolution handleValidationErrors(ValidationErrors errors) throws
> exception{ ......
>
>
> Almost - the application as it was written really wants to know which
> index positions in "List<String> lotsofemail" the mistyped e-mails are
> in, so it can write an error message such as "You typed a badly formed
> e-mail on lines 4, 5, 9, 12" and so on.
>
> The index the error occurred in in 'lotsofemail' doesn't seem to be
> available (or is it?). To compound my woes, 'lotsofemail' has been
> scrubbed of invalid e-mails by the time it reaches
> "handleValidationErrors". It now just contains the correctly formatted
> e-mails.
>
> Not complaining here, in any other situation this would be a GOOD thing,
> but my goal is to find out which position the incorrect e-mail is in. I
> can find the actual mistyped e-mail using the 'getFieldValue()' function
> from the ValidationError collection, but no obvious way to simply search
> through the original 'lotsofemail' list to deduct its original position.
> The bad e-mails have been removed, and likewise any information about
> its original index value is gone.
>
> Ok! Not giving up, maybe I can prevent 'lotsofemail' from being
> scrubbed. I try extending EmailTypeConverter in this Wil E. Coyote sort
> of way:
>
>
> public class MyEmailTypeConverter extends EmailTypeConverter {
>
> EmailTypeConverter therealconverter;
>
> public MyEmailTypeConverter(){
> therealconverter = new EmailTypeConverter()
> }
>
> public String convert(String input, Class<? extends String>
> targetType, Collection<ValidationError> errors{
>
> therealconverter.convert(input,targetType,errors);
>
> return "Bad Email: "+input;
>
> }
>
> }
>
>
>
> My extension *is* working, but not the way I expect. 'lotsofemail' is
> still scrubbed of bad e-mails, and now it has entries like "Bad Email:
> g...@email.com". How does it even do that? Spooky!
>
> So I hope I've given enough detail about my clumsy hacks to try to get
> the information I want. Given a List<> of validated input types, how can
> I tell the index values of that original list containing the invalidated
> data?
>
> Thanks again!
>
> -Derrick
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
View this message in context:
http://old.nabble.com/Getting-Array-Index-with-Stripes-Validations--tp30696933p30720418.html
Sent from the stripes-users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
