commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10780] New: - A few refactorings to Validator.java
Date Sat, 13 Jul 2002 21:54:26 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10780>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10780

A few refactorings to Validator.java

           Summary: A few refactorings to Validator.java
           Product: Commons
           Version: Nightly Builds
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Validator
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: Joe@Germuska.com


As I mentioned earlier on commons-dev, as I was looking at the source to 
commons-validator to learn more about how it works, I thought of some 
modest refactorings which I think improve the clarity of the code.  

The forthcoming patch only trims 25 lines off of the main "validate()" 
method, but I wanted to start small and make sure that Validator 
committers found this useful.  

This patch simply extracts three private methods from validate().  I also 
inverted the logic so that if the form is null, the method returns at that point 
in the code, instead of having a long block of code which is only executed 
if the form is not null followed by the same behavior.

I have two more substantial changes which I wouldn't want to do without 
buy-in.  One would be to change the logic flow that's now controlled by 
      while (bMoreActions) {...} 
to instead be more clearly associated with the action list... probably
      while (lActions.size() >0) 
(although I haven't yet looked at the question about whether the list of 
actions really needs to be sorted every time; if it didn't, you could sort it 
and then just iterate through it, which would read more clearly.)

The other change would be to move most the block that iterates through 
form fields into ValidatorAction.  This is the block marked with 
     if (va != null) {...}  
The idea would be something like va.validate(form), which seems more 
natural to me.  You actually have to pass four or five parameters, but still, it 
makes the ValidatorAction more "active" -- right now it's pretty much just a 
JavaBean.  It would also free up the possibility of subclasses of 
ValidatorAction which have radically different approaches to validation, if 
that were useful, and it would halve the size of the validate() method in 
Validator itself.

Let me reiterate that I'm using all this activity as a way to understand 
Validator better -- I don't claim to be an expert at it, and I don't want to step 
on anyones toes.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message