DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121





--- Additional Comments From [EMAIL PROTECTED]  2006-04-19 02:14 ---
(In reply to comment #4)
> Reopening for documentation review.  Are these pages up to date with the 
changes?
>  http://struts.apache.org/struts-shale/features-commons-validator.html
>  http://wiki.apache.org/struts/Shale/Validation

I believe that they do describe the current validator.  The areas expanded on 
were not specifically addressed in the documentation  anyway.  The area that 
was fuzzy before was defining a new validation rule.  There was not any direct 
association of a method parameter with a variable.  The logic just happed to 
assemble the parameters in a predefined order based on the know set of rules.  
This was also true for substitution of message parameters associated with 
variables.  

However, we might want to expand on how you can create a custom rule.  The 
CommonsVaidatorTestCase shows and example.  

JSP:





validation.xml


  
  





  
  
  
  
  
  
   
 


   



Rule Method:
//test validation rule
public static boolean isValid(String value, String colors) {
   StringTokenizer tokenizer = new StringTokenizer(colors, ",");
   
   while (tokenizer.hasMoreTokens()) {
  String color = tokenizer.nextToken().trim();
  if (value.equals(color))
 return true;
   }

   return false;
}


Do you thing that something like this would be a good addition?

-- 
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]

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2006-04-18 23:11 ---

Reopening for documentation review.  Are these pages up to date with the 
changes?
 http://struts.apache.org/struts-shale/features-commons-validator.html
 http://wiki.apache.org/struts/Shale/Validation


-- 
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]

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-18 03:25 ---
The current implementation is dependent on version 1.3 of commons validator. 
Some new conventions have been adopted for registering a validation rule in 
the validator's XML configuration file. In the action framework, validation 
was suited for declaring rules associated with a form. This worked well since 
generally a single action had the responsibility of handling all the posted 
form data at once.

However, JSF takes a component based approach. Each component has the 
responsibility of managing its posted data and rendering its state. In the 
component based world, it is easier to associated configuration values at that 
level versus what works best for struts action.

In an effort to reuse as much of commons validator and provide a method of 
registering new rules, a new convention was adopted for declaring validation 
rules. 


  

The rules declaration is the same but an added form is required to capture 
extra configuration information. The form is associated with the validation 
rule using a naming convention. The prefix of the form name 
is "org.apache.shale.validator." where "" is the validation rule name.

   
 
The form is followed by a field and the property attribute of the form has the 
same value as the rule name.

   

Within the field definition, arg's are used to define the parameters in order 
for message substitution and method argument value resolution.
There are two reserved name values for the arg node used to define messages 
and parameters.

   
   
   
   
 

The "message" name arguments defines the possible MessageFormat parameter 
substitution where the "position" corresponds to the substitution parameter.

errors.invalid={0} is invalid.

The "parameter" arguments define the variable names that hold values for the 
target validatior method identified by the validator rule name. The comma 
delimited class types in the "methodParms" value list correspond to the 
parameters by position.
  
  methodParams="java.lang.String,java.lang.String"
 
The var node is also used to explicitly define a JavaScript variable type. If 
not defined, the default is "string". The var-value is ignored because its 
captured by the shale commons validator instance.

   
   mask
  
  regexp



-- 
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]

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121





--- Additional Comments From [EMAIL PROTECTED]  2006-04-12 19:50 ---
There is another reported validator bug 38079 for dependencies being ignored.  
I have this covered on the javascript side but the server side was ignoring 
dependencies.  I suspect the reason was that JSF tries to convert the 
submitted value before passing on to the validator.  So, if you have assigned 
a converter to the component, it will validate the data type and report an 
error first.  Most of the dependencies have to do with type validation before 
another type of validation.

However, if there is not a converter assigned, the dependencies need to be 
invoked.  So, I started looking at doing this but ran into problems with the 
convention used for forming the formal parameter list for the invoking 
method.  The problem stated in this thread.  So, I put together some thought 
on how we might stylize this for JSF. 

Create a managed bean that is a place holder that holds a reference to the 
component the commons validator is associated with and an instance of the 
validator.  The map would be populated in the CommonsValidator validate 
method and cleared in a finally block in the same method.


shaleScope

  java.util.TreeMap

request



Change the messages to allow EL parameterization.  The messages would utilize 
the managed bean described above to have full access to the component and 
validator properties.  This would also simplify the logic for determining what 
arguments should be used to create the message.

errors.date=#{shaleScope.validator.arg} is not a date.

Add an expression language extension to the comma delimited token list of 
methodParams.  The EL will be used to construct the arguments list for 
invoking the method.  



Any thoughts?

-- 
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]

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121





--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 03:37 ---
I put in a patch to support validator 1.3 in the 20060411 shale nightly.  It 
covers more ground but the validation methods are not wrappered like the 
FieldChecks in Struts action.  The FieldChecks gives a standard method 
signature for new validation messages.  As it is currently implemented in 
Shale, there is a convention for determining the parameters passed to the 
validator methods and message formation which might discourage creating custom 
rules.  

I expanded the CommonsValidatorTestCase adding cases for all rule types 
including use of the ValidatorScript component to render the associated 
javascript.

I'm open for ideas on standardizing the validator rules signatures.
I'll keep this ticket open for a few days for feedback.


-- 
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]

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39121


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
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]