myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Extensions/Validator/DevDoc" by GerhardPetracek
Date Thu, 10 Dec 2009 04:42:42 GMT
Dear Wiki user,

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

The "Extensions/Validator/DevDoc" page has been changed by GerhardPetracek.
http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc?action=diff&rev1=33&rev2=34

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

  '''!!!this overview is not finished!!!'''
  
  hint to understand some concepts: extval introduces '''no''' requirement for annotations!
+ 
+ extval release numbers are directly linked with the jsf version.
+ extval 1.1.x is compatible with jsf 1.1.x
+ extval 1.2.x is compatible with jsf 1.2.x
+ extval 2.0.x is compatible with jsf 2.0.x
+ ...
+ 
+ all concepts are available for all jsf versions. to keep it short hints for specific extval
versions use just the release number e.g. x.x.3 or just r3
  
  == startup ==
  extval introduces so called startup-listener which are simple phase listener. a startup
listener is executed before restore view and de-registers itself after the init-method was
executed.<<BR>> so the logic of a startup-listener is called just once at the
very beginning of the jsf lifecycle (at the first lifecycle execution of the whole application).
@@ -254, +262 @@

  furthermore, the AbstractValidationStrategy implements the ValidationException interception
mechanism.
  
  to build a custom validation infrastructure it's possible to register a custom RendererInterceptor.
so it's possible to reuse the core mechanism and design a custom infrastructure.
+ 
+ since r3 it isn't required to check for empty values. if a validation strategy has to be
aware of empty and/or null values, it should be annotated with:
+  * @NullValueAwareValidationStrategy
+  * @EmptyValueAwareValidationStrategy
+ 
+ these annotations don't get inherited. so if you would like to change a default implementation
to be aware of null you can easily extend the default implementation, annotate the new strategy
and change the behavior via the custom implementation.
+ 
+ === @NullValueAwareValidationStrategy ===
+ if the value to be validated is null a validation strategy only gets invoked with this null
value if it is annotated with @NullValueAwareValidationStrategy
+ 
+ === @EmptyValueAwareValidationStrategy ===
+ if the value to be validated is empty a validation strategy only gets invoked with this
empty value if it is annotated with @EmptyValueAwareValidationStrategy
  
  == MessageResolver ==
  per default validation strategies reuse the jsf validation messages. anyway, extval provides
much more. out-of-the-box several default validation strategies use the message resolver mechanism
which uses ''validationErrorMsgKey'' of an annotation to resolve the internationalized message
for a given key. if there's no value for the key, the equivalent jsf message is used (if possible).
@@ -638, +658 @@

  }}}
  ... that means:<<BR>> the validation might lead to multiple validation error
messages. if it's required to display a single message which summarizes the validation error,
it's possible to override the original validation error messages.
  
- === dev-demos ===
- [[attachment:myfaces_extval_jsr303_demo-alpha1.zip]]
- 
  ----
  
  = drafts =

Mime
View raw message