Comments below.... (**)
 

-----Original Message-----
From: James Turner [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 4:38 PM
To: 'Struts Developers List'; [EMAIL PROTECTED]
Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

The only reason I didn't go with JSTL is that I couldn't find a way to
represent the Foo[] syntax (meaning "the same index into Foo that is
being used by the field being checked") in JSTL, and that's very useful
when you're doing master-detail records where you want the Last Name for
a row to be required if the first name is filled out.  Currently, you
could do this as: ((*this* != null) OR (Firstname[] == null)), how would
you do this in a JSTL syntax?

** Good point. I forgot about that feature of validatewhen. I read up on
what was out there on validatewhen. That is a good feature. I dig it now. I
retract my earlier statement of dropping validatewhen.

** I still think there should be a JSTL validator rule in addition to
validatewhen. JSTL just fits well in this space. 

 (Still on vacation in Ohio, but back in the land of broadband after
living through 24Kb hell in Chillicothe)

** I was just in Cincinnati, Ohio. I go to Ohio a lot on biz (mostly
Columbus). I live in Tucson AZ.

> -----Original Message-----
> From: Rick Hightower [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 26, 2003 5:43 PM
> To: 'Struts Developers List'; [EMAIL PROTECTED]
> Subject: RE: JSTL EL Validator rule: A better requiredif and 
> validatewhen using JSTL
> 
> 
> Comments below... (**)
> 
> David Graham:
> requiredif was released with 1.1, validwhen will be released 
> with 1.2, I will -1 any other changes like this for 1.2 
> because we're too late in the cycle for something like this.  
> 
> ** Okay. No problem. I was merely stating that I give it a +1 
> (although my vote does not count as I am not a contributor or 
> committer). I did not know how late in the cycle you all were.
> 
> Ted is already working on cutting 1.2 and nobody wants 
> another 1.1 release cycle situation.
> 
> ** Excellent. I did not know that. Good to hear. I give Ted a 
> big +1. (I loved his book).
> 
> David Graham:
> That's not how Struts works.  James spent the time to test 
> and commit validwhen and it will be released with 1.2.  
> 
> ** Understood. I was not negating the work James did. I was 
> merely expressing my opinion. I love the idea of 
> validatewhen, just not the implementation. I've read James' 
> book on Struts and I respect his talent and ability. I think 
> JSTL should have been selected instead. If I was voting back 
> then and my vote counted, I would have given it a -1. I give 
> James a +1 for effort.
> 
> 
> David Graham:
> I agree that using the EL for validation makes sense for the 
> reasons you stated.  
> 
> ** Cool. Finally I feel some sunshine. I was beginning to 
> think you did not like this idea.
> 
> David Graham:
> This would get Struts away from the restrictive requiredif 
> rule and the ANTLR generated validwhen rule.  
> 
> *** Yes. Yes. Yes.
> 
> David Graham:
> Using the standard EL would be a Good Thing.  
> 
> *** Yes.
> 
> David Graham:
> However, Struts 1.1 is based on Servlet 2.2 which prevents
> the use of Servlet 2.3 features (the EL) in the standard distro.  
> 
> *** Bummer. I did not know this. What a drag!
> *** Are you sure? I think you can use the validator rule with 
> 2.2. Why couldn't you? (excuse my ignorance) I believe you.
> 
> 
> David Graham:
> An EL based validation could live in the contrib directory 
> along with the struts-el taglib.
> 
> ** Excellent. At least it would have good company.
> ** Okay. Is this where it lives until Struts is based on 
> Servlet 2.3+ not Servlet 2.2?
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to