David Graham et al. I can feel the train derailing off the tracks. Screeeeeeeeeeeeeeeeech! For a moment let's pretend that I never mentioned BSF or Rhino. I want to get your collective thoughts on JSTL EL Validator Rule.
JSTL EL Validator Rule (validatejstl) ------------------ What feedback do you have for the JSTL EL validator rule? David mentioned some disdain for Rhino/JavaScript. What about using JSTL EL to compare fields in a form for a rule? How do you think this approach compares to requiredif and validatewhen? OPTION REQUIREDIF Is it better to create a complex and verbose set of options like requiredif to get rid of reliance on an expression language? (IMO very few folks use this because it is too complex) OPTION VALIDATEWHEN Is it better to create a custom expression language just for validation like validatewhen? Would you prefer requiredif, validatewhen, or validatejstl to be part of the next version of Struts? Or none of them? Last I heard validatewhen will be part of the next release of Struts. I think this JSTL EL Validator rule should be included instead. Creating another expression language for this problem space does not make sense when a perfectly good expression language like JSTL EL is available. It does not make sense to maintain a second expression language when Jakarta already has JSTL, which is better and more mature. JSTL EL is pervasive, e.g., JSTL EL tags are recommended over legacy struts tags. I've received some feedback from a few struts users (clients and peers). They love the idea of JSTL EL validator rule. It just makes so much sense and solves the problem of doing validation that involves relationships between form fields. This is a hole in the validator framework that gets filled quite nicely by validatejstl. The beauty of this is it is so small. Okay... I am changing tracks to a different conversation. BSF Validator Rule -------------------- This is a separate issue from the JSTL EL Validator Rule. Perhaps this could be a separate conversation. Having a validate-bsf rule would not necessitate running Rhino... it would merely be an option. The validator framework would never have to start Rhino (JavaScript), Jython (Python), JRuby (Ruby), or any scripting language unless the web application developer wanted to use this feature. I like the thought of Rhino because I could create scripts on the client and the server, and only have one set of validation scripts. I think this is a better alternative than having to maintain two sets of code that does the same thing in two languages. Again, this would be an option, not required. ** More Comments below... Rick Hightower Chief Technology Officer Trivera Technologies http://www.triveratech.com 520 290 6855 (Phone) 520 977 8605 (Mobile) -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 6:51 AM To: Struts Developers List Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL > I am using the JSTL EL Validator that I wrote, but not the BSF or OGNL > ones I assume this plan involves running Rhino as the server side Javascript engine? I don't think that's a good idea. **Why? Size? Performance? Overhead? What if Rhino was only an option (as I am suggesting)? Would you still be against Rhino if it is only an option not a requirement? Validator shouldn't have to start up a Javascript engine on the server just to do some validations. ** I agree. This is why I never suggested such a thing. ** It would not have to start JavaScript. This would be an *option*, it would only start up JavaScript if you used the validate-javascript rule (more likely validate-bsf). Javascript is a client side validation tool that's a convenience to users. ** I agree. The real benefit from Validator is the server side checks it performs which should remain in Java. ** I agree. This is an augmentation not a replacement. I am not suggesting the that validator framework have any dependence on JavaScript/Rhino. This would all be included and encapsulated in one validator rule. ** Hmmmm... what if you could do a simple expression like this.... form.passwordCheck != value Or something like this form.startDate < value and replace one ActionForm class (40+ lines of code). ** Less code to write means less code to maintain. ** I think JSTL EL and JavaScript are valid options for doing comparison of form fields. Using the BSF, the user could pick any Java scripting language (Bean Shell, Jython, JRuby or whatever). Duplication is evil. It would be nice to avoid duplication if possible. ** What were your thoughts on JSTL EL as an expression language for doing form field relationship comparisons? ** I'll come up with a proof of concept for BSF later. For now I would love to get your thoughts on JSTL EL. David <snip> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
