DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34849>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 ------- Additional Comments From [EMAIL PROTECTED] 2005-05-12 00:51 ------- About the expression names (IMO): "expression" is too long and too close to regular expression, jexl is too specific. I did come up with 'el' because it was short, but I agree that 'test' sounds better and it should not collide with validwhen. > 1) Its not supported by the original author and pretty much anyone else. a) First of all validWhen looks too complicated and people have tendency to avoid touching complex things. Also any change required hacking the parser's code - which means couple of hours waisted just to figure out how the parser works. b) EL Validator is just bridge between Validator and JEXL - so until there is a little support from JEXL team we should be safe, on the other hand it should not be hard to switch to different EL implementation. All this validator does is setting context for JEXL evaluator, if you find in the future something better then you can easily change the EL evaluator. EL is widely used in web world and I think that it is the easiest to use (so far). c) As noted before it was written using one class that creates page context from HttpServletRequest and ServletContext and that is why every one can fix it quickly. > 2) Inadequate documentation and no examples in the examples webapp. a) The idea behind creating this validator was the fact that people know and already use EL, why should they learn something else. If one knows EL s/he should be fine and be able to use it. b) Beside validator's specific documentation there is JEXL documentation (http://jakarta.apache.org/commons/jexl/reference/syntax.html#Functions), and one can look for EL documentation. > 3) No unit tests provided. Do you mean unit test for 'test' evaluation? If yes either call: validateEL with bean, ValidatorAction, Field instance, ActionMessages, request and application - that is all. If you just want to evaluate the expression take a look at the source code (or check JEXL docs) > 4) Debugging when it goes wrong was a real pain. I did try to add meaningful debug messages. On the other hand the validWhen expression was hard to debug because it was hard to read at the first place - here even none technical person can read it - this already was tested:) And about the package it has clear servlet dependencies so IMO it is closer to struts validator, and since it is in struts package I guess it should go there. Unless someone wants to extract the Validator. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]