[Myfaces Wiki] Update of "Extensions/Validator/DevDoc/Drafts" by RudyDeBusscher

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "Extensions/Validator/DevDoc/Drafts" page has been changed by RudyDeBusscher.
http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc/Drafts?action=diff&rev1=13&rev2=14

--------------------------------------------------

  
  it should be implemented via a generic approach - that means concrete validation strategies should '''not''' check it manually.
  
- moreover, @Expression should provide an attribute which points to the expression evaluator. so it's possible to create custom expressions by providing a custom evaluator.
+ moreover, @Expression should provide an attribute which points to the expression evaluator. so it's possible to create custom expressions by providing a custom evaluator. See also the ReferenceResolver idea, maybe expression evaluator could build further on that basis.
  
  furthermore, it should also work for component initialization.
  
@@ -142, +142 @@

  it's linked via the type of the key (which is annotated with @ParameterKey)
  TODO: methods for ParameterProcessor
  
+ ----
+ == brainstorming - ideas in progress ==
+ 
+ === reference resolver ===
+ 
+ Add the possibility of a Custom reference resolver for cross validation.
+ 
+ With the cross validation annotations, the developer can specify an expression to identify the other value(s) used for validation.
+ At this moment EL expressions and a limited version of Java variable notation is allowed.
+ 
+ With the addition of a ReferenceResolver interface, (some default implementations for EL and (full) Java variable notations could be foreseen) it allows the developer to implement their own resolving mechanism or notations.
+ 
+ The annotations used in Cross field validation will have an additional property resolverClass by default as follows
+ {{{
+ Class<? extends ReferenceResolver> resolverClass() default DefaultExtvalReferenceResolver.class; 
+ }}}
+ The referenceResolver interface has a single method resolveReference that could be implemented to allow custom resolving machanisms (like a MyJNDIResolver)
+ {{{
+ public interface ReferenceResolver {
+ 
+ 	ReferencedValue resolveReference(final String targetValue, final MetaDataEntry metadataEntry);
+ }}}
+ 
+ There is another extension point for the developers, the DefaultExtvalReferenceResolver. It has a list of ReferenceGrammar 's (contains by default the EL and Java variable notations).  The developers can add their own 'grammars' so custom notations can be developed to allow something like bean->property%indexList%.
+ 
+ The grammars have the InvocationOrder attribute so custom, developers made, grammars could be placed before or after the default ones.  The order is important since the first grammar that is found to understand the reference, is used the evaluate it.
+ 
+ For backward compatibility the DefaultExtvalReferenceResolver.class is taken as reference resolver when the property resolverClass isn't found on the cross validation annotation.
+