You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Rudy De Busscher <rd...@gmail.com> on 2010/04/26 15:41:36 UTC
Re: ExtVal: Rendering component with visual indication for required
fields
hello,
The main issue with your requirement is that at the time of the rendering of
the outputlabel, the input text isn't treated yet (because the label is most
of the time in front of the input field). So the required property of the
input field isn't set yet by the extval framework. (only the information of
the view is applied, not the annotations on the properties of the classes)
You mention also the renderer interceptor. But standard this renderer is
only hit for any editableValueHolder( like input fields or drop downs).
Since those are the type of components we are interested in ( in doing the
validation).
The labels aren't treated at this moment (see processComponent method in
AbstractValidationInterceptor) so you should write a custom renderer
interceptor to achieve it.
Your requirements is already on my development list (as an add-on) for a few
months now but had not the time to start with it.
So you need to create (at least) the following items:
- A custom renderer interceptor for handling the output labels
- A component initializer that put the * in front of it (caution that it
isn't done multiple times)
- The component initializer should search for the referenced component (by
the for attribute) and do the component initialization of this
EditableValueHolder. Now the @NotNull is taken into account and the * can
be placed.
You can also look at the Trinidad support module
http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support.
It has a label that is capable of putting a * behind the text so it is
possible that there is already the kind of solution to your problem. You
need to port it then only to the standard JSF (or use Trinidad in your
project).
Regards
Rudy
On 26 April 2010 14:57, <my...@arcor.de> wrote:
> Hi there,
>
> I've found some information at
> http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc, that it is
> possible to mark components who require a value via a component initializer.
> In addition I would like to use bean validation and to annotate a class'
> attributes and mark the input field or even the label of the input field:
>
> 1. @NotNull for an attribute let's say "name"
> 2. Having an output label referencing an input field
> 3. Marking all labels referencing to required fields with a '*' resulting
> in "*name"
>
> I also found the renderer interceptor which seems to be a better choice for
> me, since I want to manipulate the rendering of the label rather than the
> input component.
>
> Any suggestions?
>
> Thanks.
>
> Traumziele - von Beschreibung bis Buchung jetzt kompakt auf den
> Reise-Seiten von Arcor.de! http://www.arcor.de/rd/footer.reise
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
@rudy:
thx for committing it to the sandbox.
i reused some parts of it and combined it with my suggestion.
as mentioned by rudy - esp. for extval-constraints it's better to use
component initializers.
however, the bv module is a bit different. it's also possible to
use component initializers, however, you would have to care about a lot of
bv-details.
>currently< the bv module doesn't expose a lot. in comparison to the core
and the property-validation module it isn't that easy to expose useful utils
which provide all bv-mechanisms and additional extval/bv features.
at least for the first version of the bv-module the intention was to expose
only few api's and utils.
so we have time to think e.g. about useful utils which are aware of all
bv-features.
i'll commit the add-on quite soon!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/28 Rudy De Busscher <rd...@gmail.com>
> Tom,
>
> I quickly assembled the add-on I was thinking about a few months ago. You
> can find it here (1)
>
> If you check out the code and do a mvn install in the requiredLabel
> directory, the add-on is locally available.
>
> You then can use it in your project by including following dependency in
> your POM.
> <dependency>
> <groupId>sandbox890.extensions.validator.addon</groupId>
> <artifactId>required-label</artifactId>
>
> <version>1.2.3-SNAPSHOT</version>
> </dependency>
>
> It summarizes the discussions we had here how you could implement the
> requirement of showing a marker. I did a quick test with the @Required
> annotation and it works as expected. The Bean validation annotations
> should
> also work.
>
> (1) http://sandbox890.googlecode.com/svn/trunk/addons
>
> regards
> Rudy.
>
>
> On 28 April 2010 00:55, Gerhard Petracek <ge...@gmail.com>
> wrote:
>
> > hi tom,
> >
> > some additions:
> >
> > first of all: thx for your questions. such questions allow us to improve
> > the
> > documentation!
> > (+ usually there is a simple solution provided by extval and you don't
> have
> > to care about such extval internals.)
> >
> > @renderer interceptors:
> > the concept allows extval to do all the magic it offers. however, usually
> > it's an internal concept.
> > you just need it e.g. for add-ons (the label support you would like to
> > implement is such an add-on)
> >
> > *@meta-data transformers*
> > if you have custom constraints, you normally impl. a meta-data
> transformer
> > for each annotation you would like to use for component initialization.
> > *and that's it.*
> > *
> > *
> > *(in case of bv it's a bit more difficult - e.g.: you have to care about
> > group validation, composite constraints,...).*
> > *
> > *
> > you can transform information provided by concrete meta-data to a generic
> > representation.
> > e.g. @Size (bv) and @Length (extval) provide the same information. so you
> > just have to impl. a transformer e.g. for @Size which extracts the
> > information.
> > as soon as you forward the extracted information to extval, the framework
> > does the rest (if it knows how to handle the provided information). so
> you
> > don't have to care about all the other details and internals.
> >
> > @component initialization (i just use trinidad as concrete example):
> > you just have to impl. a component initializer e.g. for your component
> lib
> > if
> > - you have (input) components which provide special features and the
> > components aren't supported by extval (or an extval-add-on).
> > - you have a new type of meta-data (e.g. if you would like to add a
> > client-side validator for validating @EMail)
> >
> > e.g. trinidad offers client-side validation. so the optional trinidad
> > module
> > of extval uses the information provided by the transformers to add
> > client-side validators and to set properties of the trinidad components.
> so
> > trinidad isn't aware of extal. it just gets plain (initialized) trinidad
> > components. the trinidad support module isn't aware of a concrete
> > annotation
> > like @Length - it just knows that there is a generic representation to
> > express e.g. min and max length (independent of the used constraint). ->
> > you
> > get client-side validation based on constraints and support modules like
> > the
> > trinidad module aren't aware of the concrete annotations. so you can
> impl.
> > your custom constraints or use bv constraints,... - as soon as you
> > transform
> > the provided information to a known (generic) format, extval is able to
> use
> > the information to prepare the components for the rendering process.
> > (+ there are further possibilities which depend on the concrete
> > company/projects.)
> >
> > @your suggestion:
> > as you see - you don't have to use all mechanisms provided by extval -
> your
> > impl. also works. the only downside is that you have to support features
> > like group validation, composite constraints, validation payload,... on
> > your
> > own (+ the impl. depends on a bv constraint - so we can't use it as
> generic
> > add-on).
> >
> > if you impl. it based on my example (just without trinidad), you could
> > reuse
> > all features provided by extval and you don't have to care about
> mechanisms
> > like group-validation,... - you can delegate such tasks to extval.
> >
> > additional hint:
> > the trinidad support module autom. activates initialization of the
> required
> > attribute [1] (by default initialization of the required attribute is
> > deactivated) -> if you use my suggestion without trinidad, you also have
> to
> > activate the initialization of the required attribute in the startup
> > listener.
> >
> > regards,
> > gerhard
> >
> > [1]
> >
> >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/startup/TrinidadModuleStartupListener.java
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2010/4/27 Rudy De Busscher <rd...@gmail.com>
> >
> > > Hi Tom,
> > >
> > > a little more explanation of the *"... and do the component
> > initialization
> > > of this EditableValueHolder"* .
> > >
> > > When you have an outputLabel in the RendererInterceptor, the
> > > EditableValueHolder that goes with it, (the component referenced in the
> > for
> > > attribute) isn't initialized by ExtVal yet. So if you ask the Required
> > > attribute of it, it will return false, no matter what annotations there
> > are
> > > placed on the property in the backing bean. (except of course when you
> > have
> > > set the required attribute in the screen).
> > >
> > > So if you want to know if the input field is required at that time you
> > must
> > > analyze the annotations. The method
> > > ExtValUtils.configureComponentWithMetaData() does just that so you can
> > look
> > > at the required property of the UIInput after the method executed.
> > >
> > > Why RendererInterceptor and component initialization ??
> > > Well the RendererInterceptor has more functionality then just
> > intercepting
> > > the rendering of the component. It adds extra functionality for encode
> > and
> > > decode. So the component initializer is made to add information from
> the
> > > annotations to the UIComponent just before rendering. But the
> > interceptor
> > > is also responsible for coordination of the validation after a decode
> is
> > > done.
> > >
> > > In your case, a label has nothing to decode so there is no need to have
> > > this
> > > separation.
> > >
> > > Hopes this clarifies a bit.
> > >
> > > regards
> > > Rudy.
> > >
> > > On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
> > >
> > > > Hi Gerhard,
> > > >
> > > > what I had already used before asking in the mailing list was:
> > > > - ExtVal Core
> > > > - BeanValidation (using JSR-303 annotations)
> > > > - PropertyValidation (using basic code for custom cross validation
> > > > annotation and provided out-of-the-box annotations such as
> @RequiredIf)
> > > > - I did not want to use Trinidad since other component libraries are
> to
> > > be
> > > > used in the project.
> > > > - I have absolutely no validation code in the html templates (no
> > > validator
> > > > tags, no required attribute, nothing of that at all), only using
> > > > annotations
> > > > and in consequence separating page structure/layout from validation
> > rules
> > > > in
> > > > the domain objects (also founded in the organization of the
> development
> > > > teams).
> > > >
> > > > This combination works perfect so far: validating the data according
> to
> > > the
> > > > annotations, transforming messages und even generating a html
> maxlength
> > > > attribute for @Size.max (nice!).
> > > >
> > > > Since I found it quite hard to understand how ExtVal is working in
> > detail
> > > > (even with your hints and links stated), I found a very simple
> solution
> > > > that
> > > > is working for me:
> > > > - I asked myself why do I need a renderer interceptor AND a component
> > > > initializer? From my point of view adding the '*' to the label text
> is
> > > more
> > > > a question of rendering the label's text. And I could not figure out
> > what
> > > > Rudy meant with "... and do the component initialization of this
> > > > EditableValueHolder" or what to do since I want to change the label
> not
> > > the
> > > > input component.
> > > > - By obmitting the component initializer, there is no need for meta
> > data
> > > > and
> > > > a transformer...
> > > > - I used some code I found in ExtVal classes, especially from
> > > ExtValUtils.
> > > >
> > > > So this is my simple (non standard?) solution which works for the
> > > @NotNull
> > > > annotation:
> > > >
> > > > public class RequiredLabelRendererInterceptor extends
> > > > AbstractRendererInterceptor {
> > > >
> > > > public static final String REQUIRED_SYMBOL = "*";
> > > >
> > > > @Override
> > > > public void beforeEncodeBegin(FacesContext facesContext,
> > > UIComponent
> > > > uiComponent, Renderer wrapped) throws IOException {
> > > >
> > > > if (uiComponent instanceof HtmlOutputLabel) {
> > > >
> > > > HtmlOutputLabel labelComp = (HtmlOutputLabel)
> > > > uiComponent;
> > > > UIComponent inputComp = ...; // find by label
> > > > attribute 'for'
> > > >
> > > > MetaDataExtractor extractor =
> > > > createMetaDataExtractor();
> > > > for (MetaDataEntry entry :
> > > > extractor.extract(facesContext, inputComp).getMetaDataEntries()) {
> > > >
> > > checkAndHandleRequiredAttribute(labelComp,
> > > > entry.getKey());
> > > > }
> > > > }
> > > > }
> > > >
> > > > private MetaDataExtractor createMetaDataExtractor() {
> > > > return ExtValContext.getContext().getFactoryFinder()
> > > >
> > > > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> > > > ComponentMetaDataExtractorFactory.class)
> > > > .create();
> > > > }
> > > >
> > > > private void checkAndHandleRequiredAttribute(HtmlOutputLabel
> > > > labelComp, String key) {
> > > >
> > > > if (NotNull.class.getName().equals(key)) {
> > > > String label = (String) labelComp.getValue();
> > > > if (!label.startsWith(REQUIRED_SYMBOL)) {
> > > >
> > > > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > > A question to:
> > > > >> e.g.: instead of using coreOutputLabel at:
> > > > >> ExtValUtils.configureComponentWithMetaData(facesContext,
> > > > >> coreOutputLabel, metaDataResult); you could use the
> targetComponent
> > > > >> (= the input component). after this call you can check if the
> > > > >> targetComponent is required.
> > > >
> > > > Does that mean after configuring the component's attribute 'required'
> > > would
> > > > be set? I didn't try that. Is there really a need for the component
> > > > initialize and initiating the call via
> > > > ExtValUtils.configureComponentWithMetaData()?
> > > >
> > > > For my already mentioned @RequiredExactlyOneOf cross validation
> > > annotation
> > > > (which works fine regarding validation), I managed to render all
> labels
> > > > belonging to the specified attributes via the renderer interceptor.
> But
> > > > this
> > > > only works if the annotation is defined at the attribute that occurs
> > > first
> > > > in the html in order to manipulate the labels that are rendered later
> > on.
> > > > Possibly there would be a better solution to avoid this tight
> coupling
> > by
> > > > really using ExtVal's infrastructure!?
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > > > > Gesendet: Dienstag, 27. April 2010 00:45
> > > > > An: MyFaces Discussion
> > > > > Betreff: Re: ExtVal: Rendering component with visual indication for
> > > > > required fields
> > > > >
> > > > > hi thomas,
> > > > >
> > > > > basically you have 3 possibilities with extval:
> > > > > - use simple but dynamic validation, jpa based validation and
> > > > > cross-validation -> use extval-core + extval-property-validation (+
> > > > > your
> > > > > custom constraints)
> > > > > - use bean-validation + some advanced extval mechanisms for it ->
> > use
> > > > > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > > > > bv-constraints)
> > > > > - create your own validation module(s)/concepts -> use extval-core
> +
> > > > > your
> > > > > own mechanisms on top of it
> > > > >
> > > > > for sure you can combine all modules. you just have to take care
> that
> > > > > you
> > > > > don't mix different types of constraints and their concepts (esp.
> in
> > > > > combination with extval add-ons). however, i would suggest that you
> > > > > just use
> > > > > one validation-module of extval. and as soon as you are using it
> for
> > a
> > > > > real
> > > > > app, you should also think about tweaking it (e.g. see [1])
> > > > >
> > > > > two (simple) sample setups for extval + bv are available at [2] and
> > > > > [3].
> > > > > a nice intro is available at [4].
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > > [1]
> > > http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > > > > [2]
> > > > >
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > mples/hello_bean-validation/
> > > > > [3]
> > > > >
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > mples/feature-set_02/
> > > > > [4]
> > > > >
> > http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<
> http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html>
> > > <
> > http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html
> >
> > > >
> > > >
> > >
> >
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
i committed the first versions of the add-ons at [1] and [2].
-> you are welcome to test it!
regards,
gerhard
[1]
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/required_label
[2]
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval.bv/required_label
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/28 Gerhard Petracek <ge...@gmail.com>
> hi tom,
>
> yes - the add-on i'll commit will also work with bv!
>
> regards,
> gerhard
>
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2010/4/28 Tom M. <my...@arcor.de>
>
> Hi Gerhard, hi Rudy,
>>
>> thanks for your explanation so far. MetaData, Transformers, Component
>> Initializers and so on have become clear(er) to me now.
>>
>> Thanks for the coded add-on which covers some more aspects than I thought
>> of
>> (possibly EL expression in the label’s value, etc.) and which is working
>> for
>> ExtVal based annotations. I changed my renderer only code to your example.
>>
>> Still I have to say as in a mail of mine before, this is NOT working for
>> bean validation annotations since in
>> ExtValUtils.getTransformedMetaDataWith() no meta data is extracted because
>> a
>> validation strategy class cannot be located through different naming
>> conventions (like '
>> javax.validation.constraints.NotNull[Validation]Strategy'). Seems there is
>> some configuration or mapping missing? I could not find any hints in
>> Rudy's
>> code.
>>
>> Only if I leave out the check for !metaDataResult.isEmpty() it is working,
>> the setting of the attribute required is done in
>>
>> org.apache.myfaces.extensions.validator.beanval.HtmlCoreComponentsComponentI
>> nitializer since the super call isComponentRequired(UIComponent) returns
>> true what is not based on the annotations but on other component
>> attributes
>> like not being disabled nor being readonly.
>>
>> Can you took another look into this?
>>
>> Thank you.
>>
>> Tom
>>
>>
>>
>> > -----Ursprüngliche Nachricht-----
>> > Von: Rudy De Busscher [mailto:rdebusscher@gmail.com]
>> > Gesendet: Mittwoch, 28. April 2010 12:00
>> > An: MyFaces Discussion
>> > Betreff: Re: ExtVal: Rendering component with visual indication for
>> > required fields
>> >
>> > Tom,
>> >
>> > I quickly assembled the add-on I was thinking about a few months ago.
>> > You
>> > can find it here (1)
>> >
>> > If you check out the code and do a mvn install in the requiredLabel
>> > directory, the add-on is locally available.
>> >
>> > You then can use it in your project by including following dependency
>> > in
>> > your POM.
>> > <dependency>
>> > <groupId>sandbox890.extensions.validator.addon</groupId>
>> > <artifactId>required-label</artifactId>
>> >
>> > <version>1.2.3-SNAPSHOT</version>
>> > </dependency>
>> >
>> > It summarizes the discussions we had here how you could implement the
>> > requirement of showing a marker. I did a quick test with the @Required
>> > annotation and it works as expected. The Bean validation annotations
>> > should
>> > also work.
>> >
>> > (1) http://sandbox890.googlecode.com/svn/trunk/addons
>> >
>> > regards
>> > Rudy.
>> >
>> >
>> > On 28 April 2010 00:55, Gerhard Petracek <ge...@gmail.com>
>> > wrote:
>> >
>> > > hi tom,
>> > >
>> > > some additions:
>> > >
>> > > first of all: thx for your questions. such questions allow us to
>> > improve
>> > > the
>> > > documentation!
>> > > (+ usually there is a simple solution provided by extval and you
>> > don't have
>> > > to care about such extval internals.)
>> > >
>> > > @renderer interceptors:
>> > > the concept allows extval to do all the magic it offers. however,
>> > usually
>> > > it's an internal concept.
>> > > you just need it e.g. for add-ons (the label support you would like
>> > to
>> > > implement is such an add-on)
>> > >
>> > > *@meta-data transformers*
>> > > if you have custom constraints, you normally impl. a meta-data
>> > transformer
>> > > for each annotation you would like to use for component
>> > initialization.
>> > > *and that's it.*
>> > > *
>> > > *
>> > > *(in case of bv it's a bit more difficult - e.g.: you have to care
>> > about
>> > > group validation, composite constraints,...).*
>> > > *
>> > > *
>> > > you can transform information provided by concrete meta-data to a
>> > generic
>> > > representation.
>> > > e.g. @Size (bv) and @Length (extval) provide the same information. so
>> > you
>> > > just have to impl. a transformer e.g. for @Size which extracts the
>> > > information.
>> > > as soon as you forward the extracted information to extval, the
>> > framework
>> > > does the rest (if it knows how to handle the provided information).
>> > so you
>> > > don't have to care about all the other details and internals.
>> > >
>> > > @component initialization (i just use trinidad as concrete example):
>> > > you just have to impl. a component initializer e.g. for your
>> > component lib
>> > > if
>> > > - you have (input) components which provide special features and the
>> > > components aren't supported by extval (or an extval-add-on).
>> > > - you have a new type of meta-data (e.g. if you would like to add a
>> > > client-side validator for validating @EMail)
>> > >
>> > > e.g. trinidad offers client-side validation. so the optional trinidad
>> > > module
>> > > of extval uses the information provided by the transformers to add
>> > > client-side validators and to set properties of the trinidad
>> > components. so
>> > > trinidad isn't aware of extal. it just gets plain (initialized)
>> > trinidad
>> > > components. the trinidad support module isn't aware of a concrete
>> > > annotation
>> > > like @Length - it just knows that there is a generic representation
>> > to
>> > > express e.g. min and max length (independent of the used constraint).
>> > ->
>> > > you
>> > > get client-side validation based on constraints and support modules
>> > like
>> > > the
>> > > trinidad module aren't aware of the concrete annotations. so you can
>> > impl.
>> > > your custom constraints or use bv constraints,... - as soon as you
>> > > transform
>> > > the provided information to a known (generic) format, extval is able
>> > to use
>> > > the information to prepare the components for the rendering process.
>> > > (+ there are further possibilities which depend on the concrete
>> > > company/projects.)
>> > >
>> > > @your suggestion:
>> > > as you see - you don't have to use all mechanisms provided by extval
>> > - your
>> > > impl. also works. the only downside is that you have to support
>> > features
>> > > like group validation, composite constraints, validation payload,...
>> > on
>> > > your
>> > > own (+ the impl. depends on a bv constraint - so we can't use it as
>> > generic
>> > > add-on).
>> > >
>> > > if you impl. it based on my example (just without trinidad), you
>> > could
>> > > reuse
>> > > all features provided by extval and you don't have to care about
>> > mechanisms
>> > > like group-validation,... - you can delegate such tasks to extval.
>> > >
>> > > additional hint:
>> > > the trinidad support module autom. activates initialization of the
>> > required
>> > > attribute [1] (by default initialization of the required attribute is
>> > > deactivated) -> if you use my suggestion without trinidad, you also
>> > have to
>> > > activate the initialization of the required attribute in the startup
>> > > listener.
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > > [1]
>> > >
>> > >
>> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/com
>> > ponent-support/trinidad-
>> > support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/
>> > startup/TrinidadModuleStartupListener.java
>> > >
>> > > http://www.irian.at
>> > >
>> > > Your JSF powerhouse -
>> > > JSF Consulting, Development and
>> > > Courses in English and German
>> > >
>> > > Professional Support for Apache MyFaces
>> > >
>> > >
>> > >
>> > > 2010/4/27 Rudy De Busscher <rd...@gmail.com>
>> > >
>> > > > Hi Tom,
>> > > >
>> > > > a little more explanation of the *"... and do the component
>> > > initialization
>> > > > of this EditableValueHolder"* .
>> > > >
>> > > > When you have an outputLabel in the RendererInterceptor, the
>> > > > EditableValueHolder that goes with it, (the component referenced in
>> > the
>> > > for
>> > > > attribute) isn't initialized by ExtVal yet. So if you ask the
>> > Required
>> > > > attribute of it, it will return false, no matter what annotations
>> > there
>> > > are
>> > > > placed on the property in the backing bean. (except of course when
>> > you
>> > > have
>> > > > set the required attribute in the screen).
>> > > >
>> > > > So if you want to know if the input field is required at that time
>> > you
>> > > must
>> > > > analyze the annotations. The method
>> > > > ExtValUtils.configureComponentWithMetaData() does just that so you
>> > can
>> > > look
>> > > > at the required property of the UIInput after the method executed.
>> > > >
>> > > > Why RendererInterceptor and component initialization ??
>> > > > Well the RendererInterceptor has more functionality then just
>> > > intercepting
>> > > > the rendering of the component. It adds extra functionality for
>> > encode
>> > > and
>> > > > decode. So the component initializer is made to add information
>> > from the
>> > > > annotations to the UIComponent just before rendering. But the
>> > > interceptor
>> > > > is also responsible for coordination of the validation after a
>> > decode is
>> > > > done.
>> > > >
>> > > > In your case, a label has nothing to decode so there is no need to
>> > have
>> > > > this
>> > > > separation.
>> > > >
>> > > > Hopes this clarifies a bit.
>> > > >
>> > > > regards
>> > > > Rudy.
>> > > >
>> > > > On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
>> > > >
>> > > > > Hi Gerhard,
>> > > > >
>> > > > > what I had already used before asking in the mailing list was:
>> > > > > - ExtVal Core
>> > > > > - BeanValidation (using JSR-303 annotations)
>> > > > > - PropertyValidation (using basic code for custom cross
>> > validation
>> > > > > annotation and provided out-of-the-box annotations such as
>> > @RequiredIf)
>> > > > > - I did not want to use Trinidad since other component libraries
>> > are to
>> > > > be
>> > > > > used in the project.
>> > > > > - I have absolutely no validation code in the html templates (no
>> > > > validator
>> > > > > tags, no required attribute, nothing of that at all), only using
>> > > > > annotations
>> > > > > and in consequence separating page structure/layout from
>> > validation
>> > > rules
>> > > > > in
>> > > > > the domain objects (also founded in the organization of the
>> > development
>> > > > > teams).
>> > > > >
>> > > > > This combination works perfect so far: validating the data
>> > according to
>> > > > the
>> > > > > annotations, transforming messages und even generating a html
>> > maxlength
>> > > > > attribute for @Size.max (nice!).
>> > > > >
>> > > > > Since I found it quite hard to understand how ExtVal is working
>> > in
>> > > detail
>> > > > > (even with your hints and links stated), I found a very simple
>> > solution
>> > > > > that
>> > > > > is working for me:
>> > > > > - I asked myself why do I need a renderer interceptor AND a
>> > component
>> > > > > initializer? From my point of view adding the '*' to the label
>> > text is
>> > > > more
>> > > > > a question of rendering the label's text. And I could not figure
>> > out
>> > > what
>> > > > > Rudy meant with "... and do the component initialization of this
>> > > > > EditableValueHolder" or what to do since I want to change the
>> > label not
>> > > > the
>> > > > > input component.
>> > > > > - By obmitting the component initializer, there is no need for
>> > meta
>> > > data
>> > > > > and
>> > > > > a transformer...
>> > > > > - I used some code I found in ExtVal classes, especially from
>> > > > ExtValUtils.
>> > > > >
>> > > > > So this is my simple (non standard?) solution which works for the
>> > > > @NotNull
>> > > > > annotation:
>> > > > >
>> > > > > public class RequiredLabelRendererInterceptor extends
>> > > > > AbstractRendererInterceptor {
>> > > > >
>> > > > > public static final String REQUIRED_SYMBOL = "*";
>> > > > >
>> > > > > @Override
>> > > > > public void beforeEncodeBegin(FacesContext facesContext,
>> > > > UIComponent
>> > > > > uiComponent, Renderer wrapped) throws IOException {
>> > > > >
>> > > > > if (uiComponent instanceof HtmlOutputLabel) {
>> > > > >
>> > > > > HtmlOutputLabel labelComp =
>> > (HtmlOutputLabel)
>> > > > > uiComponent;
>> > > > > UIComponent inputComp = ...; // find by
>> > label
>> > > > > attribute 'for'
>> > > > >
>> > > > > MetaDataExtractor extractor =
>> > > > > createMetaDataExtractor();
>> > > > > for (MetaDataEntry entry :
>> > > > > extractor.extract(facesContext, inputComp).getMetaDataEntries())
>> > {
>> > > > >
>> > > > checkAndHandleRequiredAttribute(labelComp,
>> > > > > entry.getKey());
>> > > > > }
>> > > > > }
>> > > > > }
>> > > > >
>> > > > > private MetaDataExtractor createMetaDataExtractor() {
>> > > > > return
>> > ExtValContext.getContext().getFactoryFinder()
>> > > > >
>> > > > > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
>> > > > > ComponentMetaDataExtractorFactory.class)
>> > > > > .create();
>> > > > > }
>> > > > >
>> > > > > private void
>> > checkAndHandleRequiredAttribute(HtmlOutputLabel
>> > > > > labelComp, String key) {
>> > > > >
>> > > > > if (NotNull.class.getName().equals(key)) {
>> > > > > String label = (String)
>> > labelComp.getValue();
>> > > > > if (!label.startsWith(REQUIRED_SYMBOL)) {
>> > > > >
>> > > > > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
>> > > > > }
>> > > > > }
>> > > > > }
>> > > > > }
>> > > > >
>> > > > > A question to:
>> > > > > >> e.g.: instead of using coreOutputLabel at:
>> > > > > >> ExtValUtils.configureComponentWithMetaData(facesContext,
>> > > > > >> coreOutputLabel, metaDataResult); you could use the
>> > targetComponent
>> > > > > >> (= the input component). after this call you can check if the
>> > > > > >> targetComponent is required.
>> > > > >
>> > > > > Does that mean after configuring the component's attribute
>> > 'required'
>> > > > would
>> > > > > be set? I didn't try that. Is there really a need for the
>> > component
>> > > > > initialize and initiating the call via
>> > > > > ExtValUtils.configureComponentWithMetaData()?
>> > > > >
>> > > > > For my already mentioned @RequiredExactlyOneOf cross validation
>> > > > annotation
>> > > > > (which works fine regarding validation), I managed to render all
>> > labels
>> > > > > belonging to the specified attributes via the renderer
>> > interceptor. But
>> > > > > this
>> > > > > only works if the annotation is defined at the attribute that
>> > occurs
>> > > > first
>> > > > > in the html in order to manipulate the labels that are rendered
>> > later
>> > > on.
>> > > > > Possibly there would be a better solution to avoid this tight
>> > coupling
>> > > by
>> > > > > really using ExtVal's infrastructure!?
>> > > > >
>> > > > > Tom
>> > > > >
>> > > > >
>> > > > >
>> > > > > > -----Ursprüngliche Nachricht-----
>> > > > > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> > > > > > Gesendet: Dienstag, 27. April 2010 00:45
>> > > > > > An: MyFaces Discussion
>> > > > > > Betreff: Re: ExtVal: Rendering component with visual indication
>> > for
>> > > > > > required fields
>> > > > > >
>> > > > > > hi thomas,
>> > > > > >
>> > > > > > basically you have 3 possibilities with extval:
>> > > > > > - use simple but dynamic validation, jpa based validation and
>> > > > > > cross-validation -> use extval-core + extval-property-
>> > validation (+
>> > > > > > your
>> > > > > > custom constraints)
>> > > > > > - use bean-validation + some advanced extval mechanisms for it
>> > ->
>> > > use
>> > > > > > extval-core + extval-bean-validation + an impl. of bv (+ custom
>> > > > > > bv-constraints)
>> > > > > > - create your own validation module(s)/concepts -> use extval-
>> > core +
>> > > > > > your
>> > > > > > own mechanisms on top of it
>> > > > > >
>> > > > > > for sure you can combine all modules. you just have to take
>> > care that
>> > > > > > you
>> > > > > > don't mix different types of constraints and their concepts
>> > (esp. in
>> > > > > > combination with extval add-ons). however, i would suggest that
>> > you
>> > > > > > just use
>> > > > > > one validation-module of extval. and as soon as you are using
>> > it for
>> > > a
>> > > > > > real
>> > > > > > app, you should also think about tweaking it (e.g. see [1])
>> > > > > >
>> > > > > > two (simple) sample setups for extval + bv are available at [2]
>> > and
>> > > > > > [3].
>> > > > > > a nice intro is available at [4].
>> > > > > >
>> > > > > > regards,
>> > > > > > gerhard
>> > > > > >
>> > > > > > [1]
>> > > > http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
>> > > > > > [2]
>> > > > > >
>> > > >
>> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
>> > > > > > mples/hello_bean-validation/
>> > > > > > [3]
>> > > > > >
>> > > >
>> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
>> > > > > > mples/feature-set_02/
>> > > > > > [4]
>> > > > > >
>> > >
>> > http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<
>> > http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
>> > l>
>> > > > <
>> > >
>> > http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
>> > l>
>> > > > >
>> > > > >
>> > > >
>> > >
>>
>>
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi tom,
yes - the add-on i'll commit will also work with bv!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/28 Tom M. <my...@arcor.de>
> Hi Gerhard, hi Rudy,
>
> thanks for your explanation so far. MetaData, Transformers, Component
> Initializers and so on have become clear(er) to me now.
>
> Thanks for the coded add-on which covers some more aspects than I thought
> of
> (possibly EL expression in the label’s value, etc.) and which is working
> for
> ExtVal based annotations. I changed my renderer only code to your example.
>
> Still I have to say as in a mail of mine before, this is NOT working for
> bean validation annotations since in
> ExtValUtils.getTransformedMetaDataWith() no meta data is extracted because
> a
> validation strategy class cannot be located through different naming
> conventions (like '
> javax.validation.constraints.NotNull[Validation]Strategy'). Seems there is
> some configuration or mapping missing? I could not find any hints in Rudy's
> code.
>
> Only if I leave out the check for !metaDataResult.isEmpty() it is working,
> the setting of the attribute required is done in
>
> org.apache.myfaces.extensions.validator.beanval.HtmlCoreComponentsComponentI
> nitializer since the super call isComponentRequired(UIComponent) returns
> true what is not based on the annotations but on other component attributes
> like not being disabled nor being readonly.
>
> Can you took another look into this?
>
> Thank you.
>
> Tom
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Rudy De Busscher [mailto:rdebusscher@gmail.com]
> > Gesendet: Mittwoch, 28. April 2010 12:00
> > An: MyFaces Discussion
> > Betreff: Re: ExtVal: Rendering component with visual indication for
> > required fields
> >
> > Tom,
> >
> > I quickly assembled the add-on I was thinking about a few months ago.
> > You
> > can find it here (1)
> >
> > If you check out the code and do a mvn install in the requiredLabel
> > directory, the add-on is locally available.
> >
> > You then can use it in your project by including following dependency
> > in
> > your POM.
> > <dependency>
> > <groupId>sandbox890.extensions.validator.addon</groupId>
> > <artifactId>required-label</artifactId>
> >
> > <version>1.2.3-SNAPSHOT</version>
> > </dependency>
> >
> > It summarizes the discussions we had here how you could implement the
> > requirement of showing a marker. I did a quick test with the @Required
> > annotation and it works as expected. The Bean validation annotations
> > should
> > also work.
> >
> > (1) http://sandbox890.googlecode.com/svn/trunk/addons
> >
> > regards
> > Rudy.
> >
> >
> > On 28 April 2010 00:55, Gerhard Petracek <ge...@gmail.com>
> > wrote:
> >
> > > hi tom,
> > >
> > > some additions:
> > >
> > > first of all: thx for your questions. such questions allow us to
> > improve
> > > the
> > > documentation!
> > > (+ usually there is a simple solution provided by extval and you
> > don't have
> > > to care about such extval internals.)
> > >
> > > @renderer interceptors:
> > > the concept allows extval to do all the magic it offers. however,
> > usually
> > > it's an internal concept.
> > > you just need it e.g. for add-ons (the label support you would like
> > to
> > > implement is such an add-on)
> > >
> > > *@meta-data transformers*
> > > if you have custom constraints, you normally impl. a meta-data
> > transformer
> > > for each annotation you would like to use for component
> > initialization.
> > > *and that's it.*
> > > *
> > > *
> > > *(in case of bv it's a bit more difficult - e.g.: you have to care
> > about
> > > group validation, composite constraints,...).*
> > > *
> > > *
> > > you can transform information provided by concrete meta-data to a
> > generic
> > > representation.
> > > e.g. @Size (bv) and @Length (extval) provide the same information. so
> > you
> > > just have to impl. a transformer e.g. for @Size which extracts the
> > > information.
> > > as soon as you forward the extracted information to extval, the
> > framework
> > > does the rest (if it knows how to handle the provided information).
> > so you
> > > don't have to care about all the other details and internals.
> > >
> > > @component initialization (i just use trinidad as concrete example):
> > > you just have to impl. a component initializer e.g. for your
> > component lib
> > > if
> > > - you have (input) components which provide special features and the
> > > components aren't supported by extval (or an extval-add-on).
> > > - you have a new type of meta-data (e.g. if you would like to add a
> > > client-side validator for validating @EMail)
> > >
> > > e.g. trinidad offers client-side validation. so the optional trinidad
> > > module
> > > of extval uses the information provided by the transformers to add
> > > client-side validators and to set properties of the trinidad
> > components. so
> > > trinidad isn't aware of extal. it just gets plain (initialized)
> > trinidad
> > > components. the trinidad support module isn't aware of a concrete
> > > annotation
> > > like @Length - it just knows that there is a generic representation
> > to
> > > express e.g. min and max length (independent of the used constraint).
> > ->
> > > you
> > > get client-side validation based on constraints and support modules
> > like
> > > the
> > > trinidad module aren't aware of the concrete annotations. so you can
> > impl.
> > > your custom constraints or use bv constraints,... - as soon as you
> > > transform
> > > the provided information to a known (generic) format, extval is able
> > to use
> > > the information to prepare the components for the rendering process.
> > > (+ there are further possibilities which depend on the concrete
> > > company/projects.)
> > >
> > > @your suggestion:
> > > as you see - you don't have to use all mechanisms provided by extval
> > - your
> > > impl. also works. the only downside is that you have to support
> > features
> > > like group validation, composite constraints, validation payload,...
> > on
> > > your
> > > own (+ the impl. depends on a bv constraint - so we can't use it as
> > generic
> > > add-on).
> > >
> > > if you impl. it based on my example (just without trinidad), you
> > could
> > > reuse
> > > all features provided by extval and you don't have to care about
> > mechanisms
> > > like group-validation,... - you can delegate such tasks to extval.
> > >
> > > additional hint:
> > > the trinidad support module autom. activates initialization of the
> > required
> > > attribute [1] (by default initialization of the required attribute is
> > > deactivated) -> if you use my suggestion without trinidad, you also
> > have to
> > > activate the initialization of the required attribute in the startup
> > > listener.
> > >
> > > regards,
> > > gerhard
> > >
> > > [1]
> > >
> > >
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/com
> > ponent-support/trinidad-
> > support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/
> > startup/TrinidadModuleStartupListener.java
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> > >
> > > 2010/4/27 Rudy De Busscher <rd...@gmail.com>
> > >
> > > > Hi Tom,
> > > >
> > > > a little more explanation of the *"... and do the component
> > > initialization
> > > > of this EditableValueHolder"* .
> > > >
> > > > When you have an outputLabel in the RendererInterceptor, the
> > > > EditableValueHolder that goes with it, (the component referenced in
> > the
> > > for
> > > > attribute) isn't initialized by ExtVal yet. So if you ask the
> > Required
> > > > attribute of it, it will return false, no matter what annotations
> > there
> > > are
> > > > placed on the property in the backing bean. (except of course when
> > you
> > > have
> > > > set the required attribute in the screen).
> > > >
> > > > So if you want to know if the input field is required at that time
> > you
> > > must
> > > > analyze the annotations. The method
> > > > ExtValUtils.configureComponentWithMetaData() does just that so you
> > can
> > > look
> > > > at the required property of the UIInput after the method executed.
> > > >
> > > > Why RendererInterceptor and component initialization ??
> > > > Well the RendererInterceptor has more functionality then just
> > > intercepting
> > > > the rendering of the component. It adds extra functionality for
> > encode
> > > and
> > > > decode. So the component initializer is made to add information
> > from the
> > > > annotations to the UIComponent just before rendering. But the
> > > interceptor
> > > > is also responsible for coordination of the validation after a
> > decode is
> > > > done.
> > > >
> > > > In your case, a label has nothing to decode so there is no need to
> > have
> > > > this
> > > > separation.
> > > >
> > > > Hopes this clarifies a bit.
> > > >
> > > > regards
> > > > Rudy.
> > > >
> > > > On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
> > > >
> > > > > Hi Gerhard,
> > > > >
> > > > > what I had already used before asking in the mailing list was:
> > > > > - ExtVal Core
> > > > > - BeanValidation (using JSR-303 annotations)
> > > > > - PropertyValidation (using basic code for custom cross
> > validation
> > > > > annotation and provided out-of-the-box annotations such as
> > @RequiredIf)
> > > > > - I did not want to use Trinidad since other component libraries
> > are to
> > > > be
> > > > > used in the project.
> > > > > - I have absolutely no validation code in the html templates (no
> > > > validator
> > > > > tags, no required attribute, nothing of that at all), only using
> > > > > annotations
> > > > > and in consequence separating page structure/layout from
> > validation
> > > rules
> > > > > in
> > > > > the domain objects (also founded in the organization of the
> > development
> > > > > teams).
> > > > >
> > > > > This combination works perfect so far: validating the data
> > according to
> > > > the
> > > > > annotations, transforming messages und even generating a html
> > maxlength
> > > > > attribute for @Size.max (nice!).
> > > > >
> > > > > Since I found it quite hard to understand how ExtVal is working
> > in
> > > detail
> > > > > (even with your hints and links stated), I found a very simple
> > solution
> > > > > that
> > > > > is working for me:
> > > > > - I asked myself why do I need a renderer interceptor AND a
> > component
> > > > > initializer? From my point of view adding the '*' to the label
> > text is
> > > > more
> > > > > a question of rendering the label's text. And I could not figure
> > out
> > > what
> > > > > Rudy meant with "... and do the component initialization of this
> > > > > EditableValueHolder" or what to do since I want to change the
> > label not
> > > > the
> > > > > input component.
> > > > > - By obmitting the component initializer, there is no need for
> > meta
> > > data
> > > > > and
> > > > > a transformer...
> > > > > - I used some code I found in ExtVal classes, especially from
> > > > ExtValUtils.
> > > > >
> > > > > So this is my simple (non standard?) solution which works for the
> > > > @NotNull
> > > > > annotation:
> > > > >
> > > > > public class RequiredLabelRendererInterceptor extends
> > > > > AbstractRendererInterceptor {
> > > > >
> > > > > public static final String REQUIRED_SYMBOL = "*";
> > > > >
> > > > > @Override
> > > > > public void beforeEncodeBegin(FacesContext facesContext,
> > > > UIComponent
> > > > > uiComponent, Renderer wrapped) throws IOException {
> > > > >
> > > > > if (uiComponent instanceof HtmlOutputLabel) {
> > > > >
> > > > > HtmlOutputLabel labelComp =
> > (HtmlOutputLabel)
> > > > > uiComponent;
> > > > > UIComponent inputComp = ...; // find by
> > label
> > > > > attribute 'for'
> > > > >
> > > > > MetaDataExtractor extractor =
> > > > > createMetaDataExtractor();
> > > > > for (MetaDataEntry entry :
> > > > > extractor.extract(facesContext, inputComp).getMetaDataEntries())
> > {
> > > > >
> > > > checkAndHandleRequiredAttribute(labelComp,
> > > > > entry.getKey());
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > private MetaDataExtractor createMetaDataExtractor() {
> > > > > return
> > ExtValContext.getContext().getFactoryFinder()
> > > > >
> > > > > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> > > > > ComponentMetaDataExtractorFactory.class)
> > > > > .create();
> > > > > }
> > > > >
> > > > > private void
> > checkAndHandleRequiredAttribute(HtmlOutputLabel
> > > > > labelComp, String key) {
> > > > >
> > > > > if (NotNull.class.getName().equals(key)) {
> > > > > String label = (String)
> > labelComp.getValue();
> > > > > if (!label.startsWith(REQUIRED_SYMBOL)) {
> > > > >
> > > > > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> > > > > }
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > A question to:
> > > > > >> e.g.: instead of using coreOutputLabel at:
> > > > > >> ExtValUtils.configureComponentWithMetaData(facesContext,
> > > > > >> coreOutputLabel, metaDataResult); you could use the
> > targetComponent
> > > > > >> (= the input component). after this call you can check if the
> > > > > >> targetComponent is required.
> > > > >
> > > > > Does that mean after configuring the component's attribute
> > 'required'
> > > > would
> > > > > be set? I didn't try that. Is there really a need for the
> > component
> > > > > initialize and initiating the call via
> > > > > ExtValUtils.configureComponentWithMetaData()?
> > > > >
> > > > > For my already mentioned @RequiredExactlyOneOf cross validation
> > > > annotation
> > > > > (which works fine regarding validation), I managed to render all
> > labels
> > > > > belonging to the specified attributes via the renderer
> > interceptor. But
> > > > > this
> > > > > only works if the annotation is defined at the attribute that
> > occurs
> > > > first
> > > > > in the html in order to manipulate the labels that are rendered
> > later
> > > on.
> > > > > Possibly there would be a better solution to avoid this tight
> > coupling
> > > by
> > > > > really using ExtVal's infrastructure!?
> > > > >
> > > > > Tom
> > > > >
> > > > >
> > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > > > > > Gesendet: Dienstag, 27. April 2010 00:45
> > > > > > An: MyFaces Discussion
> > > > > > Betreff: Re: ExtVal: Rendering component with visual indication
> > for
> > > > > > required fields
> > > > > >
> > > > > > hi thomas,
> > > > > >
> > > > > > basically you have 3 possibilities with extval:
> > > > > > - use simple but dynamic validation, jpa based validation and
> > > > > > cross-validation -> use extval-core + extval-property-
> > validation (+
> > > > > > your
> > > > > > custom constraints)
> > > > > > - use bean-validation + some advanced extval mechanisms for it
> > ->
> > > use
> > > > > > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > > > > > bv-constraints)
> > > > > > - create your own validation module(s)/concepts -> use extval-
> > core +
> > > > > > your
> > > > > > own mechanisms on top of it
> > > > > >
> > > > > > for sure you can combine all modules. you just have to take
> > care that
> > > > > > you
> > > > > > don't mix different types of constraints and their concepts
> > (esp. in
> > > > > > combination with extval add-ons). however, i would suggest that
> > you
> > > > > > just use
> > > > > > one validation-module of extval. and as soon as you are using
> > it for
> > > a
> > > > > > real
> > > > > > app, you should also think about tweaking it (e.g. see [1])
> > > > > >
> > > > > > two (simple) sample setups for extval + bv are available at [2]
> > and
> > > > > > [3].
> > > > > > a nice intro is available at [4].
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > > [1]
> > > > http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > > > > > [2]
> > > > > >
> > > >
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > > mples/hello_bean-validation/
> > > > > > [3]
> > > > > >
> > > >
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > > mples/feature-set_02/
> > > > > > [4]
> > > > > >
> > >
> > http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<
> > http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
> > l>
> > > > <
> > >
> > http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
> > l>
> > > > >
> > > > >
> > > >
> > >
>
>
AW: ExtVal: Rendering component with visual indication for required fields
Posted by "Tom M." <my...@arcor.de>.
Hi Gerhard, hi Rudy,
thanks for your explanation so far. MetaData, Transformers, Component
Initializers and so on have become clear(er) to me now.
Thanks for the coded add-on which covers some more aspects than I thought of
(possibly EL expression in the labels value, etc.) and which is working for
ExtVal based annotations. I changed my renderer only code to your example.
Still I have to say as in a mail of mine before, this is NOT working for
bean validation annotations since in
ExtValUtils.getTransformedMetaDataWith() no meta data is extracted because a
validation strategy class cannot be located through different naming
conventions (like '
javax.validation.constraints.NotNull[Validation]Strategy'). Seems there is
some configuration or mapping missing? I could not find any hints in Rudy's
code.
Only if I leave out the check for !metaDataResult.isEmpty() it is working,
the setting of the attribute required is done in
org.apache.myfaces.extensions.validator.beanval.HtmlCoreComponentsComponentI
nitializer since the super call isComponentRequired(UIComponent) returns
true what is not based on the annotations but on other component attributes
like not being disabled nor being readonly.
Can you took another look into this?
Thank you.
Tom
> -----Ursprüngliche Nachricht-----
> Von: Rudy De Busscher [mailto:rdebusscher@gmail.com]
> Gesendet: Mittwoch, 28. April 2010 12:00
> An: MyFaces Discussion
> Betreff: Re: ExtVal: Rendering component with visual indication for
> required fields
>
> Tom,
>
> I quickly assembled the add-on I was thinking about a few months ago.
> You
> can find it here (1)
>
> If you check out the code and do a mvn install in the requiredLabel
> directory, the add-on is locally available.
>
> You then can use it in your project by including following dependency
> in
> your POM.
> <dependency>
> <groupId>sandbox890.extensions.validator.addon</groupId>
> <artifactId>required-label</artifactId>
>
> <version>1.2.3-SNAPSHOT</version>
> </dependency>
>
> It summarizes the discussions we had here how you could implement the
> requirement of showing a marker. I did a quick test with the @Required
> annotation and it works as expected. The Bean validation annotations
> should
> also work.
>
> (1) http://sandbox890.googlecode.com/svn/trunk/addons
>
> regards
> Rudy.
>
>
> On 28 April 2010 00:55, Gerhard Petracek <ge...@gmail.com>
> wrote:
>
> > hi tom,
> >
> > some additions:
> >
> > first of all: thx for your questions. such questions allow us to
> improve
> > the
> > documentation!
> > (+ usually there is a simple solution provided by extval and you
> don't have
> > to care about such extval internals.)
> >
> > @renderer interceptors:
> > the concept allows extval to do all the magic it offers. however,
> usually
> > it's an internal concept.
> > you just need it e.g. for add-ons (the label support you would like
> to
> > implement is such an add-on)
> >
> > *@meta-data transformers*
> > if you have custom constraints, you normally impl. a meta-data
> transformer
> > for each annotation you would like to use for component
> initialization.
> > *and that's it.*
> > *
> > *
> > *(in case of bv it's a bit more difficult - e.g.: you have to care
> about
> > group validation, composite constraints,...).*
> > *
> > *
> > you can transform information provided by concrete meta-data to a
> generic
> > representation.
> > e.g. @Size (bv) and @Length (extval) provide the same information. so
> you
> > just have to impl. a transformer e.g. for @Size which extracts the
> > information.
> > as soon as you forward the extracted information to extval, the
> framework
> > does the rest (if it knows how to handle the provided information).
> so you
> > don't have to care about all the other details and internals.
> >
> > @component initialization (i just use trinidad as concrete example):
> > you just have to impl. a component initializer e.g. for your
> component lib
> > if
> > - you have (input) components which provide special features and the
> > components aren't supported by extval (or an extval-add-on).
> > - you have a new type of meta-data (e.g. if you would like to add a
> > client-side validator for validating @EMail)
> >
> > e.g. trinidad offers client-side validation. so the optional trinidad
> > module
> > of extval uses the information provided by the transformers to add
> > client-side validators and to set properties of the trinidad
> components. so
> > trinidad isn't aware of extal. it just gets plain (initialized)
> trinidad
> > components. the trinidad support module isn't aware of a concrete
> > annotation
> > like @Length - it just knows that there is a generic representation
> to
> > express e.g. min and max length (independent of the used constraint).
> ->
> > you
> > get client-side validation based on constraints and support modules
> like
> > the
> > trinidad module aren't aware of the concrete annotations. so you can
> impl.
> > your custom constraints or use bv constraints,... - as soon as you
> > transform
> > the provided information to a known (generic) format, extval is able
> to use
> > the information to prepare the components for the rendering process.
> > (+ there are further possibilities which depend on the concrete
> > company/projects.)
> >
> > @your suggestion:
> > as you see - you don't have to use all mechanisms provided by extval
> - your
> > impl. also works. the only downside is that you have to support
> features
> > like group validation, composite constraints, validation payload,...
> on
> > your
> > own (+ the impl. depends on a bv constraint - so we can't use it as
> generic
> > add-on).
> >
> > if you impl. it based on my example (just without trinidad), you
> could
> > reuse
> > all features provided by extval and you don't have to care about
> mechanisms
> > like group-validation,... - you can delegate such tasks to extval.
> >
> > additional hint:
> > the trinidad support module autom. activates initialization of the
> required
> > attribute [1] (by default initialization of the required attribute is
> > deactivated) -> if you use my suggestion without trinidad, you also
> have to
> > activate the initialization of the required attribute in the startup
> > listener.
> >
> > regards,
> > gerhard
> >
> > [1]
> >
> >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/com
> ponent-support/trinidad-
> support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/
> startup/TrinidadModuleStartupListener.java
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2010/4/27 Rudy De Busscher <rd...@gmail.com>
> >
> > > Hi Tom,
> > >
> > > a little more explanation of the *"... and do the component
> > initialization
> > > of this EditableValueHolder"* .
> > >
> > > When you have an outputLabel in the RendererInterceptor, the
> > > EditableValueHolder that goes with it, (the component referenced in
> the
> > for
> > > attribute) isn't initialized by ExtVal yet. So if you ask the
> Required
> > > attribute of it, it will return false, no matter what annotations
> there
> > are
> > > placed on the property in the backing bean. (except of course when
> you
> > have
> > > set the required attribute in the screen).
> > >
> > > So if you want to know if the input field is required at that time
> you
> > must
> > > analyze the annotations. The method
> > > ExtValUtils.configureComponentWithMetaData() does just that so you
> can
> > look
> > > at the required property of the UIInput after the method executed.
> > >
> > > Why RendererInterceptor and component initialization ??
> > > Well the RendererInterceptor has more functionality then just
> > intercepting
> > > the rendering of the component. It adds extra functionality for
> encode
> > and
> > > decode. So the component initializer is made to add information
> from the
> > > annotations to the UIComponent just before rendering. But the
> > interceptor
> > > is also responsible for coordination of the validation after a
> decode is
> > > done.
> > >
> > > In your case, a label has nothing to decode so there is no need to
> have
> > > this
> > > separation.
> > >
> > > Hopes this clarifies a bit.
> > >
> > > regards
> > > Rudy.
> > >
> > > On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
> > >
> > > > Hi Gerhard,
> > > >
> > > > what I had already used before asking in the mailing list was:
> > > > - ExtVal Core
> > > > - BeanValidation (using JSR-303 annotations)
> > > > - PropertyValidation (using basic code for custom cross
> validation
> > > > annotation and provided out-of-the-box annotations such as
> @RequiredIf)
> > > > - I did not want to use Trinidad since other component libraries
> are to
> > > be
> > > > used in the project.
> > > > - I have absolutely no validation code in the html templates (no
> > > validator
> > > > tags, no required attribute, nothing of that at all), only using
> > > > annotations
> > > > and in consequence separating page structure/layout from
> validation
> > rules
> > > > in
> > > > the domain objects (also founded in the organization of the
> development
> > > > teams).
> > > >
> > > > This combination works perfect so far: validating the data
> according to
> > > the
> > > > annotations, transforming messages und even generating a html
> maxlength
> > > > attribute for @Size.max (nice!).
> > > >
> > > > Since I found it quite hard to understand how ExtVal is working
> in
> > detail
> > > > (even with your hints and links stated), I found a very simple
> solution
> > > > that
> > > > is working for me:
> > > > - I asked myself why do I need a renderer interceptor AND a
> component
> > > > initializer? From my point of view adding the '*' to the label
> text is
> > > more
> > > > a question of rendering the label's text. And I could not figure
> out
> > what
> > > > Rudy meant with "... and do the component initialization of this
> > > > EditableValueHolder" or what to do since I want to change the
> label not
> > > the
> > > > input component.
> > > > - By obmitting the component initializer, there is no need for
> meta
> > data
> > > > and
> > > > a transformer...
> > > > - I used some code I found in ExtVal classes, especially from
> > > ExtValUtils.
> > > >
> > > > So this is my simple (non standard?) solution which works for the
> > > @NotNull
> > > > annotation:
> > > >
> > > > public class RequiredLabelRendererInterceptor extends
> > > > AbstractRendererInterceptor {
> > > >
> > > > public static final String REQUIRED_SYMBOL = "*";
> > > >
> > > > @Override
> > > > public void beforeEncodeBegin(FacesContext facesContext,
> > > UIComponent
> > > > uiComponent, Renderer wrapped) throws IOException {
> > > >
> > > > if (uiComponent instanceof HtmlOutputLabel) {
> > > >
> > > > HtmlOutputLabel labelComp =
> (HtmlOutputLabel)
> > > > uiComponent;
> > > > UIComponent inputComp = ...; // find by
> label
> > > > attribute 'for'
> > > >
> > > > MetaDataExtractor extractor =
> > > > createMetaDataExtractor();
> > > > for (MetaDataEntry entry :
> > > > extractor.extract(facesContext, inputComp).getMetaDataEntries())
> {
> > > >
> > > checkAndHandleRequiredAttribute(labelComp,
> > > > entry.getKey());
> > > > }
> > > > }
> > > > }
> > > >
> > > > private MetaDataExtractor createMetaDataExtractor() {
> > > > return
> ExtValContext.getContext().getFactoryFinder()
> > > >
> > > > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> > > > ComponentMetaDataExtractorFactory.class)
> > > > .create();
> > > > }
> > > >
> > > > private void
> checkAndHandleRequiredAttribute(HtmlOutputLabel
> > > > labelComp, String key) {
> > > >
> > > > if (NotNull.class.getName().equals(key)) {
> > > > String label = (String)
> labelComp.getValue();
> > > > if (!label.startsWith(REQUIRED_SYMBOL)) {
> > > >
> > > > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > > A question to:
> > > > >> e.g.: instead of using coreOutputLabel at:
> > > > >> ExtValUtils.configureComponentWithMetaData(facesContext,
> > > > >> coreOutputLabel, metaDataResult); you could use the
> targetComponent
> > > > >> (= the input component). after this call you can check if the
> > > > >> targetComponent is required.
> > > >
> > > > Does that mean after configuring the component's attribute
> 'required'
> > > would
> > > > be set? I didn't try that. Is there really a need for the
> component
> > > > initialize and initiating the call via
> > > > ExtValUtils.configureComponentWithMetaData()?
> > > >
> > > > For my already mentioned @RequiredExactlyOneOf cross validation
> > > annotation
> > > > (which works fine regarding validation), I managed to render all
> labels
> > > > belonging to the specified attributes via the renderer
> interceptor. But
> > > > this
> > > > only works if the annotation is defined at the attribute that
> occurs
> > > first
> > > > in the html in order to manipulate the labels that are rendered
> later
> > on.
> > > > Possibly there would be a better solution to avoid this tight
> coupling
> > by
> > > > really using ExtVal's infrastructure!?
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > > > > Gesendet: Dienstag, 27. April 2010 00:45
> > > > > An: MyFaces Discussion
> > > > > Betreff: Re: ExtVal: Rendering component with visual indication
> for
> > > > > required fields
> > > > >
> > > > > hi thomas,
> > > > >
> > > > > basically you have 3 possibilities with extval:
> > > > > - use simple but dynamic validation, jpa based validation and
> > > > > cross-validation -> use extval-core + extval-property-
> validation (+
> > > > > your
> > > > > custom constraints)
> > > > > - use bean-validation + some advanced extval mechanisms for it
> ->
> > use
> > > > > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > > > > bv-constraints)
> > > > > - create your own validation module(s)/concepts -> use extval-
> core +
> > > > > your
> > > > > own mechanisms on top of it
> > > > >
> > > > > for sure you can combine all modules. you just have to take
> care that
> > > > > you
> > > > > don't mix different types of constraints and their concepts
> (esp. in
> > > > > combination with extval add-ons). however, i would suggest that
> you
> > > > > just use
> > > > > one validation-module of extval. and as soon as you are using
> it for
> > a
> > > > > real
> > > > > app, you should also think about tweaking it (e.g. see [1])
> > > > >
> > > > > two (simple) sample setups for extval + bv are available at [2]
> and
> > > > > [3].
> > > > > a nice intro is available at [4].
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > > [1]
> > > http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > > > > [2]
> > > > >
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > mples/hello_bean-validation/
> > > > > [3]
> > > > >
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > > mples/feature-set_02/
> > > > > [4]
> > > > >
> >
> http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<
> http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
> l>
> > > <
> >
> http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.htm
> l>
> > > >
> > > >
> > >
> >
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Rudy De Busscher <rd...@gmail.com>.
Tom,
I quickly assembled the add-on I was thinking about a few months ago. You
can find it here (1)
If you check out the code and do a mvn install in the requiredLabel
directory, the add-on is locally available.
You then can use it in your project by including following dependency in
your POM.
<dependency>
<groupId>sandbox890.extensions.validator.addon</groupId>
<artifactId>required-label</artifactId>
<version>1.2.3-SNAPSHOT</version>
</dependency>
It summarizes the discussions we had here how you could implement the
requirement of showing a marker. I did a quick test with the @Required
annotation and it works as expected. The Bean validation annotations should
also work.
(1) http://sandbox890.googlecode.com/svn/trunk/addons
regards
Rudy.
On 28 April 2010 00:55, Gerhard Petracek <ge...@gmail.com> wrote:
> hi tom,
>
> some additions:
>
> first of all: thx for your questions. such questions allow us to improve
> the
> documentation!
> (+ usually there is a simple solution provided by extval and you don't have
> to care about such extval internals.)
>
> @renderer interceptors:
> the concept allows extval to do all the magic it offers. however, usually
> it's an internal concept.
> you just need it e.g. for add-ons (the label support you would like to
> implement is such an add-on)
>
> *@meta-data transformers*
> if you have custom constraints, you normally impl. a meta-data transformer
> for each annotation you would like to use for component initialization.
> *and that's it.*
> *
> *
> *(in case of bv it's a bit more difficult - e.g.: you have to care about
> group validation, composite constraints,...).*
> *
> *
> you can transform information provided by concrete meta-data to a generic
> representation.
> e.g. @Size (bv) and @Length (extval) provide the same information. so you
> just have to impl. a transformer e.g. for @Size which extracts the
> information.
> as soon as you forward the extracted information to extval, the framework
> does the rest (if it knows how to handle the provided information). so you
> don't have to care about all the other details and internals.
>
> @component initialization (i just use trinidad as concrete example):
> you just have to impl. a component initializer e.g. for your component lib
> if
> - you have (input) components which provide special features and the
> components aren't supported by extval (or an extval-add-on).
> - you have a new type of meta-data (e.g. if you would like to add a
> client-side validator for validating @EMail)
>
> e.g. trinidad offers client-side validation. so the optional trinidad
> module
> of extval uses the information provided by the transformers to add
> client-side validators and to set properties of the trinidad components. so
> trinidad isn't aware of extal. it just gets plain (initialized) trinidad
> components. the trinidad support module isn't aware of a concrete
> annotation
> like @Length - it just knows that there is a generic representation to
> express e.g. min and max length (independent of the used constraint). ->
> you
> get client-side validation based on constraints and support modules like
> the
> trinidad module aren't aware of the concrete annotations. so you can impl.
> your custom constraints or use bv constraints,... - as soon as you
> transform
> the provided information to a known (generic) format, extval is able to use
> the information to prepare the components for the rendering process.
> (+ there are further possibilities which depend on the concrete
> company/projects.)
>
> @your suggestion:
> as you see - you don't have to use all mechanisms provided by extval - your
> impl. also works. the only downside is that you have to support features
> like group validation, composite constraints, validation payload,... on
> your
> own (+ the impl. depends on a bv constraint - so we can't use it as generic
> add-on).
>
> if you impl. it based on my example (just without trinidad), you could
> reuse
> all features provided by extval and you don't have to care about mechanisms
> like group-validation,... - you can delegate such tasks to extval.
>
> additional hint:
> the trinidad support module autom. activates initialization of the required
> attribute [1] (by default initialization of the required attribute is
> deactivated) -> if you use my suggestion without trinidad, you also have to
> activate the initialization of the required attribute in the startup
> listener.
>
> regards,
> gerhard
>
> [1]
>
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/startup/TrinidadModuleStartupListener.java
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2010/4/27 Rudy De Busscher <rd...@gmail.com>
>
> > Hi Tom,
> >
> > a little more explanation of the *"... and do the component
> initialization
> > of this EditableValueHolder"* .
> >
> > When you have an outputLabel in the RendererInterceptor, the
> > EditableValueHolder that goes with it, (the component referenced in the
> for
> > attribute) isn't initialized by ExtVal yet. So if you ask the Required
> > attribute of it, it will return false, no matter what annotations there
> are
> > placed on the property in the backing bean. (except of course when you
> have
> > set the required attribute in the screen).
> >
> > So if you want to know if the input field is required at that time you
> must
> > analyze the annotations. The method
> > ExtValUtils.configureComponentWithMetaData() does just that so you can
> look
> > at the required property of the UIInput after the method executed.
> >
> > Why RendererInterceptor and component initialization ??
> > Well the RendererInterceptor has more functionality then just
> intercepting
> > the rendering of the component. It adds extra functionality for encode
> and
> > decode. So the component initializer is made to add information from the
> > annotations to the UIComponent just before rendering. But the
> interceptor
> > is also responsible for coordination of the validation after a decode is
> > done.
> >
> > In your case, a label has nothing to decode so there is no need to have
> > this
> > separation.
> >
> > Hopes this clarifies a bit.
> >
> > regards
> > Rudy.
> >
> > On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
> >
> > > Hi Gerhard,
> > >
> > > what I had already used before asking in the mailing list was:
> > > - ExtVal Core
> > > - BeanValidation (using JSR-303 annotations)
> > > - PropertyValidation (using basic code for custom cross validation
> > > annotation and provided out-of-the-box annotations such as @RequiredIf)
> > > - I did not want to use Trinidad since other component libraries are to
> > be
> > > used in the project.
> > > - I have absolutely no validation code in the html templates (no
> > validator
> > > tags, no required attribute, nothing of that at all), only using
> > > annotations
> > > and in consequence separating page structure/layout from validation
> rules
> > > in
> > > the domain objects (also founded in the organization of the development
> > > teams).
> > >
> > > This combination works perfect so far: validating the data according to
> > the
> > > annotations, transforming messages und even generating a html maxlength
> > > attribute for @Size.max (nice!).
> > >
> > > Since I found it quite hard to understand how ExtVal is working in
> detail
> > > (even with your hints and links stated), I found a very simple solution
> > > that
> > > is working for me:
> > > - I asked myself why do I need a renderer interceptor AND a component
> > > initializer? From my point of view adding the '*' to the label text is
> > more
> > > a question of rendering the label's text. And I could not figure out
> what
> > > Rudy meant with "... and do the component initialization of this
> > > EditableValueHolder" or what to do since I want to change the label not
> > the
> > > input component.
> > > - By obmitting the component initializer, there is no need for meta
> data
> > > and
> > > a transformer...
> > > - I used some code I found in ExtVal classes, especially from
> > ExtValUtils.
> > >
> > > So this is my simple (non standard?) solution which works for the
> > @NotNull
> > > annotation:
> > >
> > > public class RequiredLabelRendererInterceptor extends
> > > AbstractRendererInterceptor {
> > >
> > > public static final String REQUIRED_SYMBOL = "*";
> > >
> > > @Override
> > > public void beforeEncodeBegin(FacesContext facesContext,
> > UIComponent
> > > uiComponent, Renderer wrapped) throws IOException {
> > >
> > > if (uiComponent instanceof HtmlOutputLabel) {
> > >
> > > HtmlOutputLabel labelComp = (HtmlOutputLabel)
> > > uiComponent;
> > > UIComponent inputComp = ...; // find by label
> > > attribute 'for'
> > >
> > > MetaDataExtractor extractor =
> > > createMetaDataExtractor();
> > > for (MetaDataEntry entry :
> > > extractor.extract(facesContext, inputComp).getMetaDataEntries()) {
> > >
> > checkAndHandleRequiredAttribute(labelComp,
> > > entry.getKey());
> > > }
> > > }
> > > }
> > >
> > > private MetaDataExtractor createMetaDataExtractor() {
> > > return ExtValContext.getContext().getFactoryFinder()
> > >
> > > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> > > ComponentMetaDataExtractorFactory.class)
> > > .create();
> > > }
> > >
> > > private void checkAndHandleRequiredAttribute(HtmlOutputLabel
> > > labelComp, String key) {
> > >
> > > if (NotNull.class.getName().equals(key)) {
> > > String label = (String) labelComp.getValue();
> > > if (!label.startsWith(REQUIRED_SYMBOL)) {
> > >
> > > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> > > }
> > > }
> > > }
> > > }
> > >
> > > A question to:
> > > >> e.g.: instead of using coreOutputLabel at:
> > > >> ExtValUtils.configureComponentWithMetaData(facesContext,
> > > >> coreOutputLabel, metaDataResult); you could use the targetComponent
> > > >> (= the input component). after this call you can check if the
> > > >> targetComponent is required.
> > >
> > > Does that mean after configuring the component's attribute 'required'
> > would
> > > be set? I didn't try that. Is there really a need for the component
> > > initialize and initiating the call via
> > > ExtValUtils.configureComponentWithMetaData()?
> > >
> > > For my already mentioned @RequiredExactlyOneOf cross validation
> > annotation
> > > (which works fine regarding validation), I managed to render all labels
> > > belonging to the specified attributes via the renderer interceptor. But
> > > this
> > > only works if the annotation is defined at the attribute that occurs
> > first
> > > in the html in order to manipulate the labels that are rendered later
> on.
> > > Possibly there would be a better solution to avoid this tight coupling
> by
> > > really using ExtVal's infrastructure!?
> > >
> > > Tom
> > >
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > > > Gesendet: Dienstag, 27. April 2010 00:45
> > > > An: MyFaces Discussion
> > > > Betreff: Re: ExtVal: Rendering component with visual indication for
> > > > required fields
> > > >
> > > > hi thomas,
> > > >
> > > > basically you have 3 possibilities with extval:
> > > > - use simple but dynamic validation, jpa based validation and
> > > > cross-validation -> use extval-core + extval-property-validation (+
> > > > your
> > > > custom constraints)
> > > > - use bean-validation + some advanced extval mechanisms for it ->
> use
> > > > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > > > bv-constraints)
> > > > - create your own validation module(s)/concepts -> use extval-core +
> > > > your
> > > > own mechanisms on top of it
> > > >
> > > > for sure you can combine all modules. you just have to take care that
> > > > you
> > > > don't mix different types of constraints and their concepts (esp. in
> > > > combination with extval add-ons). however, i would suggest that you
> > > > just use
> > > > one validation-module of extval. and as soon as you are using it for
> a
> > > > real
> > > > app, you should also think about tweaking it (e.g. see [1])
> > > >
> > > > two (simple) sample setups for extval + bv are available at [2] and
> > > > [3].
> > > > a nice intro is available at [4].
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1]
> > http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > > > [2]
> > > >
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > mples/hello_bean-validation/
> > > > [3]
> > > >
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > > mples/feature-set_02/
> > > > [4]
> > > >
> http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html>
> > <
> http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html>
> > >
> > >
> >
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi tom,
some additions:
first of all: thx for your questions. such questions allow us to improve the
documentation!
(+ usually there is a simple solution provided by extval and you don't have
to care about such extval internals.)
@renderer interceptors:
the concept allows extval to do all the magic it offers. however, usually
it's an internal concept.
you just need it e.g. for add-ons (the label support you would like to
implement is such an add-on)
*@meta-data transformers*
if you have custom constraints, you normally impl. a meta-data transformer
for each annotation you would like to use for component initialization.
*and that's it.*
*
*
*(in case of bv it's a bit more difficult - e.g.: you have to care about
group validation, composite constraints,...).*
*
*
you can transform information provided by concrete meta-data to a generic
representation.
e.g. @Size (bv) and @Length (extval) provide the same information. so you
just have to impl. a transformer e.g. for @Size which extracts the
information.
as soon as you forward the extracted information to extval, the framework
does the rest (if it knows how to handle the provided information). so you
don't have to care about all the other details and internals.
@component initialization (i just use trinidad as concrete example):
you just have to impl. a component initializer e.g. for your component lib
if
- you have (input) components which provide special features and the
components aren't supported by extval (or an extval-add-on).
- you have a new type of meta-data (e.g. if you would like to add a
client-side validator for validating @EMail)
e.g. trinidad offers client-side validation. so the optional trinidad module
of extval uses the information provided by the transformers to add
client-side validators and to set properties of the trinidad components. so
trinidad isn't aware of extal. it just gets plain (initialized) trinidad
components. the trinidad support module isn't aware of a concrete annotation
like @Length - it just knows that there is a generic representation to
express e.g. min and max length (independent of the used constraint). -> you
get client-side validation based on constraints and support modules like the
trinidad module aren't aware of the concrete annotations. so you can impl.
your custom constraints or use bv constraints,... - as soon as you transform
the provided information to a known (generic) format, extval is able to use
the information to prepare the components for the rendering process.
(+ there are further possibilities which depend on the concrete
company/projects.)
@your suggestion:
as you see - you don't have to use all mechanisms provided by extval - your
impl. also works. the only downside is that you have to support features
like group validation, composite constraints, validation payload,... on your
own (+ the impl. depends on a bv constraint - so we can't use it as generic
add-on).
if you impl. it based on my example (just without trinidad), you could reuse
all features provided by extval and you don't have to care about mechanisms
like group-validation,... - you can delegate such tasks to extval.
additional hint:
the trinidad support module autom. activates initialization of the required
attribute [1] (by default initialization of the required attribute is
deactivated) -> if you use my suggestion without trinidad, you also have to
activate the initialization of the required attribute in the startup
listener.
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/startup/TrinidadModuleStartupListener.java
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/27 Rudy De Busscher <rd...@gmail.com>
> Hi Tom,
>
> a little more explanation of the *"... and do the component initialization
> of this EditableValueHolder"* .
>
> When you have an outputLabel in the RendererInterceptor, the
> EditableValueHolder that goes with it, (the component referenced in the for
> attribute) isn't initialized by ExtVal yet. So if you ask the Required
> attribute of it, it will return false, no matter what annotations there are
> placed on the property in the backing bean. (except of course when you have
> set the required attribute in the screen).
>
> So if you want to know if the input field is required at that time you must
> analyze the annotations. The method
> ExtValUtils.configureComponentWithMetaData() does just that so you can look
> at the required property of the UIInput after the method executed.
>
> Why RendererInterceptor and component initialization ??
> Well the RendererInterceptor has more functionality then just intercepting
> the rendering of the component. It adds extra functionality for encode and
> decode. So the component initializer is made to add information from the
> annotations to the UIComponent just before rendering. But the interceptor
> is also responsible for coordination of the validation after a decode is
> done.
>
> In your case, a label has nothing to decode so there is no need to have
> this
> separation.
>
> Hopes this clarifies a bit.
>
> regards
> Rudy.
>
> On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
>
> > Hi Gerhard,
> >
> > what I had already used before asking in the mailing list was:
> > - ExtVal Core
> > - BeanValidation (using JSR-303 annotations)
> > - PropertyValidation (using basic code for custom cross validation
> > annotation and provided out-of-the-box annotations such as @RequiredIf)
> > - I did not want to use Trinidad since other component libraries are to
> be
> > used in the project.
> > - I have absolutely no validation code in the html templates (no
> validator
> > tags, no required attribute, nothing of that at all), only using
> > annotations
> > and in consequence separating page structure/layout from validation rules
> > in
> > the domain objects (also founded in the organization of the development
> > teams).
> >
> > This combination works perfect so far: validating the data according to
> the
> > annotations, transforming messages und even generating a html maxlength
> > attribute for @Size.max (nice!).
> >
> > Since I found it quite hard to understand how ExtVal is working in detail
> > (even with your hints and links stated), I found a very simple solution
> > that
> > is working for me:
> > - I asked myself why do I need a renderer interceptor AND a component
> > initializer? From my point of view adding the '*' to the label text is
> more
> > a question of rendering the label's text. And I could not figure out what
> > Rudy meant with "... and do the component initialization of this
> > EditableValueHolder" or what to do since I want to change the label not
> the
> > input component.
> > - By obmitting the component initializer, there is no need for meta data
> > and
> > a transformer...
> > - I used some code I found in ExtVal classes, especially from
> ExtValUtils.
> >
> > So this is my simple (non standard?) solution which works for the
> @NotNull
> > annotation:
> >
> > public class RequiredLabelRendererInterceptor extends
> > AbstractRendererInterceptor {
> >
> > public static final String REQUIRED_SYMBOL = "*";
> >
> > @Override
> > public void beforeEncodeBegin(FacesContext facesContext,
> UIComponent
> > uiComponent, Renderer wrapped) throws IOException {
> >
> > if (uiComponent instanceof HtmlOutputLabel) {
> >
> > HtmlOutputLabel labelComp = (HtmlOutputLabel)
> > uiComponent;
> > UIComponent inputComp = ...; // find by label
> > attribute 'for'
> >
> > MetaDataExtractor extractor =
> > createMetaDataExtractor();
> > for (MetaDataEntry entry :
> > extractor.extract(facesContext, inputComp).getMetaDataEntries()) {
> >
> checkAndHandleRequiredAttribute(labelComp,
> > entry.getKey());
> > }
> > }
> > }
> >
> > private MetaDataExtractor createMetaDataExtractor() {
> > return ExtValContext.getContext().getFactoryFinder()
> >
> > .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> > ComponentMetaDataExtractorFactory.class)
> > .create();
> > }
> >
> > private void checkAndHandleRequiredAttribute(HtmlOutputLabel
> > labelComp, String key) {
> >
> > if (NotNull.class.getName().equals(key)) {
> > String label = (String) labelComp.getValue();
> > if (!label.startsWith(REQUIRED_SYMBOL)) {
> >
> > labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> > }
> > }
> > }
> > }
> >
> > A question to:
> > >> e.g.: instead of using coreOutputLabel at:
> > >> ExtValUtils.configureComponentWithMetaData(facesContext,
> > >> coreOutputLabel, metaDataResult); you could use the targetComponent
> > >> (= the input component). after this call you can check if the
> > >> targetComponent is required.
> >
> > Does that mean after configuring the component's attribute 'required'
> would
> > be set? I didn't try that. Is there really a need for the component
> > initialize and initiating the call via
> > ExtValUtils.configureComponentWithMetaData()?
> >
> > For my already mentioned @RequiredExactlyOneOf cross validation
> annotation
> > (which works fine regarding validation), I managed to render all labels
> > belonging to the specified attributes via the renderer interceptor. But
> > this
> > only works if the annotation is defined at the attribute that occurs
> first
> > in the html in order to manipulate the labels that are rendered later on.
> > Possibly there would be a better solution to avoid this tight coupling by
> > really using ExtVal's infrastructure!?
> >
> > Tom
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > > Gesendet: Dienstag, 27. April 2010 00:45
> > > An: MyFaces Discussion
> > > Betreff: Re: ExtVal: Rendering component with visual indication for
> > > required fields
> > >
> > > hi thomas,
> > >
> > > basically you have 3 possibilities with extval:
> > > - use simple but dynamic validation, jpa based validation and
> > > cross-validation -> use extval-core + extval-property-validation (+
> > > your
> > > custom constraints)
> > > - use bean-validation + some advanced extval mechanisms for it -> use
> > > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > > bv-constraints)
> > > - create your own validation module(s)/concepts -> use extval-core +
> > > your
> > > own mechanisms on top of it
> > >
> > > for sure you can combine all modules. you just have to take care that
> > > you
> > > don't mix different types of constraints and their concepts (esp. in
> > > combination with extval add-ons). however, i would suggest that you
> > > just use
> > > one validation-module of extval. and as soon as you are using it for a
> > > real
> > > app, you should also think about tweaking it (e.g. see [1])
> > >
> > > two (simple) sample setups for extval + bv are available at [2] and
> > > [3].
> > > a nice intro is available at [4].
> > >
> > > regards,
> > > gerhard
> > >
> > > [1]
> http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > > [2]
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > mples/hello_bean-validation/
> > > [3]
> > >
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > > mples/feature-set_02/
> > > [4]
> > > http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html
> <http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html>
> >
> >
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Rudy De Busscher <rd...@gmail.com>.
Hi Tom,
a little more explanation of the *"... and do the component initialization
of this EditableValueHolder"* .
When you have an outputLabel in the RendererInterceptor, the
EditableValueHolder that goes with it, (the component referenced in the for
attribute) isn't initialized by ExtVal yet. So if you ask the Required
attribute of it, it will return false, no matter what annotations there are
placed on the property in the backing bean. (except of course when you have
set the required attribute in the screen).
So if you want to know if the input field is required at that time you must
analyze the annotations. The method
ExtValUtils.configureComponentWithMetaData() does just that so you can look
at the required property of the UIInput after the method executed.
Why RendererInterceptor and component initialization ??
Well the RendererInterceptor has more functionality then just intercepting
the rendering of the component. It adds extra functionality for encode and
decode. So the component initializer is made to add information from the
annotations to the UIComponent just before rendering. But the interceptor
is also responsible for coordination of the validation after a decode is
done.
In your case, a label has nothing to decode so there is no need to have this
separation.
Hopes this clarifies a bit.
regards
Rudy.
On 27 April 2010 21:25, Tom M. <my...@arcor.de> wrote:
> Hi Gerhard,
>
> what I had already used before asking in the mailing list was:
> - ExtVal Core
> - BeanValidation (using JSR-303 annotations)
> - PropertyValidation (using basic code for custom cross validation
> annotation and provided out-of-the-box annotations such as @RequiredIf)
> - I did not want to use Trinidad since other component libraries are to be
> used in the project.
> - I have absolutely no validation code in the html templates (no validator
> tags, no required attribute, nothing of that at all), only using
> annotations
> and in consequence separating page structure/layout from validation rules
> in
> the domain objects (also founded in the organization of the development
> teams).
>
> This combination works perfect so far: validating the data according to the
> annotations, transforming messages und even generating a html maxlength
> attribute for @Size.max (nice!).
>
> Since I found it quite hard to understand how ExtVal is working in detail
> (even with your hints and links stated), I found a very simple solution
> that
> is working for me:
> - I asked myself why do I need a renderer interceptor AND a component
> initializer? From my point of view adding the '*' to the label text is more
> a question of rendering the label's text. And I could not figure out what
> Rudy meant with "... and do the component initialization of this
> EditableValueHolder" or what to do since I want to change the label not the
> input component.
> - By obmitting the component initializer, there is no need for meta data
> and
> a transformer...
> - I used some code I found in ExtVal classes, especially from ExtValUtils.
>
> So this is my simple (non standard?) solution which works for the @NotNull
> annotation:
>
> public class RequiredLabelRendererInterceptor extends
> AbstractRendererInterceptor {
>
> public static final String REQUIRED_SYMBOL = "*";
>
> @Override
> public void beforeEncodeBegin(FacesContext facesContext, UIComponent
> uiComponent, Renderer wrapped) throws IOException {
>
> if (uiComponent instanceof HtmlOutputLabel) {
>
> HtmlOutputLabel labelComp = (HtmlOutputLabel)
> uiComponent;
> UIComponent inputComp = ...; // find by label
> attribute 'for'
>
> MetaDataExtractor extractor =
> createMetaDataExtractor();
> for (MetaDataEntry entry :
> extractor.extract(facesContext, inputComp).getMetaDataEntries()) {
> checkAndHandleRequiredAttribute(labelComp,
> entry.getKey());
> }
> }
> }
>
> private MetaDataExtractor createMetaDataExtractor() {
> return ExtValContext.getContext().getFactoryFinder()
>
> .getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
> ComponentMetaDataExtractorFactory.class)
> .create();
> }
>
> private void checkAndHandleRequiredAttribute(HtmlOutputLabel
> labelComp, String key) {
>
> if (NotNull.class.getName().equals(key)) {
> String label = (String) labelComp.getValue();
> if (!label.startsWith(REQUIRED_SYMBOL)) {
>
> labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
> }
> }
> }
> }
>
> A question to:
> >> e.g.: instead of using coreOutputLabel at:
> >> ExtValUtils.configureComponentWithMetaData(facesContext,
> >> coreOutputLabel, metaDataResult); you could use the targetComponent
> >> (= the input component). after this call you can check if the
> >> targetComponent is required.
>
> Does that mean after configuring the component's attribute 'required' would
> be set? I didn't try that. Is there really a need for the component
> initialize and initiating the call via
> ExtValUtils.configureComponentWithMetaData()?
>
> For my already mentioned @RequiredExactlyOneOf cross validation annotation
> (which works fine regarding validation), I managed to render all labels
> belonging to the specified attributes via the renderer interceptor. But
> this
> only works if the annotation is defined at the attribute that occurs first
> in the html in order to manipulate the labels that are rendered later on.
> Possibly there would be a better solution to avoid this tight coupling by
> really using ExtVal's infrastructure!?
>
> Tom
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> > Gesendet: Dienstag, 27. April 2010 00:45
> > An: MyFaces Discussion
> > Betreff: Re: ExtVal: Rendering component with visual indication for
> > required fields
> >
> > hi thomas,
> >
> > basically you have 3 possibilities with extval:
> > - use simple but dynamic validation, jpa based validation and
> > cross-validation -> use extval-core + extval-property-validation (+
> > your
> > custom constraints)
> > - use bean-validation + some advanced extval mechanisms for it -> use
> > extval-core + extval-bean-validation + an impl. of bv (+ custom
> > bv-constraints)
> > - create your own validation module(s)/concepts -> use extval-core +
> > your
> > own mechanisms on top of it
> >
> > for sure you can combine all modules. you just have to take care that
> > you
> > don't mix different types of constraints and their concepts (esp. in
> > combination with extval add-ons). however, i would suggest that you
> > just use
> > one validation-module of extval. and as soon as you are using it for a
> > real
> > app, you should also think about tweaking it (e.g. see [1])
> >
> > two (simple) sample setups for extval + bv are available at [2] and
> > [3].
> > a nice intro is available at [4].
> >
> > regards,
> > gerhard
> >
> > [1] http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> > [2]
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > mples/hello_bean-validation/
> > [3]
> > https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> > mples/feature-set_02/
> > [4]
> > http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html<http://people.apache.org/%7Egpetracek/myfaces/extval/extval_chapter.html>
>
>
AW: ExtVal: Rendering component with visual indication for required fields
Posted by "Tom M." <my...@arcor.de>.
Hi Gerhard,
what I had already used before asking in the mailing list was:
- ExtVal Core
- BeanValidation (using JSR-303 annotations)
- PropertyValidation (using basic code for custom cross validation
annotation and provided out-of-the-box annotations such as @RequiredIf)
- I did not want to use Trinidad since other component libraries are to be
used in the project.
- I have absolutely no validation code in the html templates (no validator
tags, no required attribute, nothing of that at all), only using annotations
and in consequence separating page structure/layout from validation rules in
the domain objects (also founded in the organization of the development
teams).
This combination works perfect so far: validating the data according to the
annotations, transforming messages und even generating a html maxlength
attribute for @Size.max (nice!).
Since I found it quite hard to understand how ExtVal is working in detail
(even with your hints and links stated), I found a very simple solution that
is working for me:
- I asked myself why do I need a renderer interceptor AND a component
initializer? From my point of view adding the '*' to the label text is more
a question of rendering the label's text. And I could not figure out what
Rudy meant with "... and do the component initialization of this
EditableValueHolder" or what to do since I want to change the label not the
input component.
- By obmitting the component initializer, there is no need for meta data and
a transformer...
- I used some code I found in ExtVal classes, especially from ExtValUtils.
So this is my simple (non standard?) solution which works for the @NotNull
annotation:
public class RequiredLabelRendererInterceptor extends
AbstractRendererInterceptor {
public static final String REQUIRED_SYMBOL = "*";
@Override
public void beforeEncodeBegin(FacesContext facesContext, UIComponent
uiComponent, Renderer wrapped) throws IOException {
if (uiComponent instanceof HtmlOutputLabel) {
HtmlOutputLabel labelComp = (HtmlOutputLabel)
uiComponent;
UIComponent inputComp = ...; // find by label
attribute 'for'
MetaDataExtractor extractor =
createMetaDataExtractor();
for (MetaDataEntry entry :
extractor.extract(facesContext, inputComp).getMetaDataEntries()) {
checkAndHandleRequiredAttribute(labelComp,
entry.getKey());
}
}
}
private MetaDataExtractor createMetaDataExtractor() {
return ExtValContext.getContext().getFactoryFinder()
.getFactory(FactoryNames.COMPONENT_META_DATA_EXTRACTOR_FACTORY,
ComponentMetaDataExtractorFactory.class)
.create();
}
private void checkAndHandleRequiredAttribute(HtmlOutputLabel
labelComp, String key) {
if (NotNull.class.getName().equals(key)) {
String label = (String) labelComp.getValue();
if (!label.startsWith(REQUIRED_SYMBOL)) {
labelComp.setValue(REQUIRED_SYMBOL+labelComp.getValue());
}
}
}
}
A question to:
>> e.g.: instead of using coreOutputLabel at:
>> ExtValUtils.configureComponentWithMetaData(facesContext,
>> coreOutputLabel, metaDataResult); you could use the targetComponent
>> (= the input component). after this call you can check if the
>> targetComponent is required.
Does that mean after configuring the component's attribute 'required' would
be set? I didn't try that. Is there really a need for the component
initialize and initiating the call via
ExtValUtils.configureComponentWithMetaData()?
For my already mentioned @RequiredExactlyOneOf cross validation annotation
(which works fine regarding validation), I managed to render all labels
belonging to the specified attributes via the renderer interceptor. But this
only works if the annotation is defined at the attribute that occurs first
in the html in order to manipulate the labels that are rendered later on.
Possibly there would be a better solution to avoid this tight coupling by
really using ExtVal's infrastructure!?
Tom
> -----Ursprüngliche Nachricht-----
> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> Gesendet: Dienstag, 27. April 2010 00:45
> An: MyFaces Discussion
> Betreff: Re: ExtVal: Rendering component with visual indication for
> required fields
>
> hi thomas,
>
> basically you have 3 possibilities with extval:
> - use simple but dynamic validation, jpa based validation and
> cross-validation -> use extval-core + extval-property-validation (+
> your
> custom constraints)
> - use bean-validation + some advanced extval mechanisms for it -> use
> extval-core + extval-bean-validation + an impl. of bv (+ custom
> bv-constraints)
> - create your own validation module(s)/concepts -> use extval-core +
> your
> own mechanisms on top of it
>
> for sure you can combine all modules. you just have to take care that
> you
> don't mix different types of constraints and their concepts (esp. in
> combination with extval add-ons). however, i would suggest that you
> just use
> one validation-module of extval. and as soon as you are using it for a
> real
> app, you should also think about tweaking it (e.g. see [1])
>
> two (simple) sample setups for extval + bv are available at [2] and
> [3].
> a nice intro is available at [4].
>
> regards,
> gerhard
>
> [1] http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> [2]
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> mples/hello_bean-validation/
> [3]
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/exa
> mples/feature-set_02/
> [4]
> http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
short addition:
@ExtValUtils:
i used a local prototype - that's the reason why it didn't work for you.
however, i uploaded a working implementation for trinidad at [1].
it works with the current version (e.g. [2]).
regards,
gerhard
[1] http://people.apache.org/~gpetracek/myfaces/extval/demos/trinidad
[2] http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/27 Gerhard Petracek <ge...@gmail.com>
> hi thomas,
>
> basically you have 3 possibilities with extval:
> - use simple but dynamic validation, jpa based validation and
> cross-validation -> use extval-core + extval-property-validation (+ your
> custom constraints)
> - use bean-validation + some advanced extval mechanisms for it -> use
> extval-core + extval-bean-validation + an impl. of bv (+ custom
> bv-constraints)
> - create your own validation module(s)/concepts -> use extval-core + your
> own mechanisms on top of it
>
> for sure you can combine all modules. you just have to take care that you
> don't mix different types of constraints and their concepts (esp. in
> combination with extval add-ons). however, i would suggest that you just use
> one validation-module of extval. and as soon as you are using it for a real
> app, you should also think about tweaking it (e.g. see [1])
>
> two (simple) sample setups for extval + bv are available at [2] and [3].
> a nice intro is available at [4].
>
> regards,
> gerhard
>
> [1] http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
> [2]
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/hello_bean-validation/
> [3]
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/feature-set_02/
> [4] http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
> 2010/4/26 Tom M. <my...@arcor.de>
>
> Hi Gerhard, hi Rudy,
>>
>> thank you for your quick response.
>>
>> I tried to proceed just like you suggested but the meta data for the bean
>> validation annotations is not found. ExtValUtils.getTransformedMetaData()
>> always returns an empty map. The reason seems to be that
>> DefaultValidationStrategyFactory.create(String) only holds JPA-Mappings
>> and
>> no BV-Mappings. Am I missing some jars or where can I find something like
>> javax.validation.constraints.NotNull[Validation]Strategy or
>> bean:notNull[Validation]Strategy which is looked for?
>>
>> For my own annotation @RequiredExactlyOneOf (similar to ExtVal's
>> @RequiredIf) I managed to extract the meta data with my own transformer,
>> but
>> I have to take a closer look tomorrow how to go on from that point.
>>
>> Thomas
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> Gesendet: Montag, 26. April 2010 17:49
>> An: MyFaces Discussion
>> Betreff: Re: ExtVal: Rendering component with visual indication for
>> required
>> fields
>>
>> hi,
>>
>> short addition:
>>
>> basically it depends on the component lib you are using.
>> e.g. myfaces trinidad supports such indicators out-of-the-box (also based
>> on
>> meta-data - e.g. in combination with extval).
>> -> extval + trinidad -> no additional effort.
>>
>> without trinidad you have to implement a small add-on for extval.
>> you can have a look at [1]. you just have to replace the trinidad specific
>> parts and you have to add the indicator on your own (depending on the
>> found
>> meta-data).
>>
>> e.g.: instead of using coreOutputLabel at:
>> ExtValUtils.configureComponentWithMetaData(facesContext, coreOutputLabel,
>> metaDataResult);
>> you could use the targetComponent (= the input component). after this call
>> you can check if the targetComponent is required.
>> so you keep the compatibility with the required attribute of the component
>> and you can re-use the existing implementation of extval.
>>
>> if you are allowed to donate the add-on, i would commit it to os890 (after
>> reviewing it).
>>
>> regards,
>> gerhard
>>
>> [1]
>>
>> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/componen
>>
>> t-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/valid
>> ator/trinidad/interceptor/TrinidadRendererInterceptor.java<https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/interceptor/TrinidadRendererInterceptor.java>
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2010/4/26 Rudy De Busscher <rd...@gmail.com>
>>
>> > hello,
>> >
>> > The main issue with your requirement is that at the time of the
>> rendering
>> > of
>> > the outputlabel, the input text isn't treated yet (because the label is
>> > most
>> > of the time in front of the input field). So the required property of
>> the
>> > input field isn't set yet by the extval framework. (only the information
>> of
>> > the view is applied, not the annotations on the properties of the
>> classes)
>> >
>> > You mention also the renderer interceptor. But standard this renderer
>> is
>> > only hit for any editableValueHolder( like input fields or drop downs).
>> > Since those are the type of components we are interested in ( in doing
>> the
>> > validation).
>> > The labels aren't treated at this moment (see processComponent method in
>> > AbstractValidationInterceptor) so you should write a custom renderer
>> > interceptor to achieve it.
>> >
>> > Your requirements is already on my development list (as an add-on) for a
>> > few
>> > months now but had not the time to start with it.
>> >
>> > So you need to create (at least) the following items:
>> > - A custom renderer interceptor for handling the output labels
>> > - A component initializer that put the * in front of it (caution that it
>> > isn't done multiple times)
>> > - The component initializer should search for the referenced component
>> (by
>> > the for attribute) and do the component initialization of this
>> > EditableValueHolder. Now the @NotNull is taken into account and the *
>> can
>> > be placed.
>> >
>> > You can also look at the Trinidad support module
>> >
>> >
>>
>> http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component
>> -support/trinidad-support<http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support>
>> > .
>> > It has a label that is capable of putting a * behind the text so it is
>> > possible that there is already the kind of solution to your problem.
>> You
>> > need to port it then only to the standard JSF (or use Trinidad in your
>> > project).
>> >
>> > Regards
>> > Rudy
>> >
>> > On 26 April 2010 14:57, <my...@arcor.de> wrote:
>> >
>> > > Hi there,
>> > >
>> > > I've found some information at
>> > > http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc, that it
>> is
>> > > possible to mark components who require a value via a component
>> > initializer.
>> > > In addition I would like to use bean validation and to annotate a
>> class'
>> > > attributes and mark the input field or even the label of the input
>> field:
>> > >
>> > > 1. @NotNull for an attribute let's say "name"
>> > > 2. Having an output label referencing an input field
>> > > 3. Marking all labels referencing to required fields with a '*'
>> resulting
>> > > in "*name"
>> > >
>> > > I also found the renderer interceptor which seems to be a better
>> choice
>> > for
>> > > me, since I want to manipulate the rendering of the label rather than
>> the
>> > > input component.
>> > >
>> > > Any suggestions?
>> > >
>> > > Thanks.
>> > >
>>
>>
>
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi thomas,
basically you have 3 possibilities with extval:
- use simple but dynamic validation, jpa based validation and
cross-validation -> use extval-core + extval-property-validation (+ your
custom constraints)
- use bean-validation + some advanced extval mechanisms for it -> use
extval-core + extval-bean-validation + an impl. of bv (+ custom
bv-constraints)
- create your own validation module(s)/concepts -> use extval-core + your
own mechanisms on top of it
for sure you can combine all modules. you just have to take care that you
don't mix different types of constraints and their concepts (esp. in
combination with extval add-ons). however, i would suggest that you just use
one validation-module of extval. and as soon as you are using it for a real
app, you should also think about tweaking it (e.g. see [1])
two (simple) sample setups for extval + bv are available at [2] and [3].
a nice intro is available at [4].
regards,
gerhard
[1] http://wiki.apache.org/myfaces/Extensions/Validator/JSR303/Advanced
[2]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/hello_bean-validation/
[3]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/feature-set_02/
[4] http://people.apache.org/~gpetracek/myfaces/extval/extval_chapter.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/26 Tom M. <my...@arcor.de>
> Hi Gerhard, hi Rudy,
>
> thank you for your quick response.
>
> I tried to proceed just like you suggested but the meta data for the bean
> validation annotations is not found. ExtValUtils.getTransformedMetaData()
> always returns an empty map. The reason seems to be that
> DefaultValidationStrategyFactory.create(String) only holds JPA-Mappings and
> no BV-Mappings. Am I missing some jars or where can I find something like
> javax.validation.constraints.NotNull[Validation]Strategy or
> bean:notNull[Validation]Strategy which is looked for?
>
> For my own annotation @RequiredExactlyOneOf (similar to ExtVal's
> @RequiredIf) I managed to extract the meta data with my own transformer,
> but
> I have to take a closer look tomorrow how to go on from that point.
>
> Thomas
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> Gesendet: Montag, 26. April 2010 17:49
> An: MyFaces Discussion
> Betreff: Re: ExtVal: Rendering component with visual indication for
> required
> fields
>
> hi,
>
> short addition:
>
> basically it depends on the component lib you are using.
> e.g. myfaces trinidad supports such indicators out-of-the-box (also based
> on
> meta-data - e.g. in combination with extval).
> -> extval + trinidad -> no additional effort.
>
> without trinidad you have to implement a small add-on for extval.
> you can have a look at [1]. you just have to replace the trinidad specific
> parts and you have to add the indicator on your own (depending on the found
> meta-data).
>
> e.g.: instead of using coreOutputLabel at:
> ExtValUtils.configureComponentWithMetaData(facesContext, coreOutputLabel,
> metaDataResult);
> you could use the targetComponent (= the input component). after this call
> you can check if the targetComponent is required.
> so you keep the compatibility with the required attribute of the component
> and you can re-use the existing implementation of extval.
>
> if you are allowed to donate the add-on, i would commit it to os890 (after
> reviewing it).
>
> regards,
> gerhard
>
> [1]
>
> https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/componen
>
> t-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/valid
> ator/trinidad/interceptor/TrinidadRendererInterceptor.java
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2010/4/26 Rudy De Busscher <rd...@gmail.com>
>
> > hello,
> >
> > The main issue with your requirement is that at the time of the rendering
> > of
> > the outputlabel, the input text isn't treated yet (because the label is
> > most
> > of the time in front of the input field). So the required property of
> the
> > input field isn't set yet by the extval framework. (only the information
> of
> > the view is applied, not the annotations on the properties of the
> classes)
> >
> > You mention also the renderer interceptor. But standard this renderer is
> > only hit for any editableValueHolder( like input fields or drop downs).
> > Since those are the type of components we are interested in ( in doing
> the
> > validation).
> > The labels aren't treated at this moment (see processComponent method in
> > AbstractValidationInterceptor) so you should write a custom renderer
> > interceptor to achieve it.
> >
> > Your requirements is already on my development list (as an add-on) for a
> > few
> > months now but had not the time to start with it.
> >
> > So you need to create (at least) the following items:
> > - A custom renderer interceptor for handling the output labels
> > - A component initializer that put the * in front of it (caution that it
> > isn't done multiple times)
> > - The component initializer should search for the referenced component
> (by
> > the for attribute) and do the component initialization of this
> > EditableValueHolder. Now the @NotNull is taken into account and the *
> can
> > be placed.
> >
> > You can also look at the Trinidad support module
> >
> >
>
> http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component
> -support/trinidad-support
> > .
> > It has a label that is capable of putting a * behind the text so it is
> > possible that there is already the kind of solution to your problem. You
> > need to port it then only to the standard JSF (or use Trinidad in your
> > project).
> >
> > Regards
> > Rudy
> >
> > On 26 April 2010 14:57, <my...@arcor.de> wrote:
> >
> > > Hi there,
> > >
> > > I've found some information at
> > > http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc, that it is
> > > possible to mark components who require a value via a component
> > initializer.
> > > In addition I would like to use bean validation and to annotate a
> class'
> > > attributes and mark the input field or even the label of the input
> field:
> > >
> > > 1. @NotNull for an attribute let's say "name"
> > > 2. Having an output label referencing an input field
> > > 3. Marking all labels referencing to required fields with a '*'
> resulting
> > > in "*name"
> > >
> > > I also found the renderer interceptor which seems to be a better choice
> > for
> > > me, since I want to manipulate the rendering of the label rather than
> the
> > > input component.
> > >
> > > Any suggestions?
> > >
> > > Thanks.
> > >
>
>
AW: ExtVal: Rendering component with visual indication for required fields
Posted by "Tom M." <my...@arcor.de>.
Hi Gerhard, hi Rudy,
thank you for your quick response.
I tried to proceed just like you suggested but the meta data for the bean
validation annotations is not found. ExtValUtils.getTransformedMetaData()
always returns an empty map. The reason seems to be that
DefaultValidationStrategyFactory.create(String) only holds JPA-Mappings and
no BV-Mappings. Am I missing some jars or where can I find something like
javax.validation.constraints.NotNull[Validation]Strategy or
bean:notNull[Validation]Strategy which is looked for?
For my own annotation @RequiredExactlyOneOf (similar to ExtVal's
@RequiredIf) I managed to extract the meta data with my own transformer, but
I have to take a closer look tomorrow how to go on from that point.
Thomas
-----Ursprüngliche Nachricht-----
Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
Gesendet: Montag, 26. April 2010 17:49
An: MyFaces Discussion
Betreff: Re: ExtVal: Rendering component with visual indication for required
fields
hi,
short addition:
basically it depends on the component lib you are using.
e.g. myfaces trinidad supports such indicators out-of-the-box (also based on
meta-data - e.g. in combination with extval).
-> extval + trinidad -> no additional effort.
without trinidad you have to implement a small add-on for extval.
you can have a look at [1]. you just have to replace the trinidad specific
parts and you have to add the indicator on your own (depending on the found
meta-data).
e.g.: instead of using coreOutputLabel at:
ExtValUtils.configureComponentWithMetaData(facesContext, coreOutputLabel,
metaDataResult);
you could use the targetComponent (= the input component). after this call
you can check if the targetComponent is required.
so you keep the compatibility with the required attribute of the component
and you can re-use the existing implementation of extval.
if you are allowed to donate the add-on, i would commit it to os890 (after
reviewing it).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/componen
t-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/valid
ator/trinidad/interceptor/TrinidadRendererInterceptor.java
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/26 Rudy De Busscher <rd...@gmail.com>
> hello,
>
> The main issue with your requirement is that at the time of the rendering
> of
> the outputlabel, the input text isn't treated yet (because the label is
> most
> of the time in front of the input field). So the required property of the
> input field isn't set yet by the extval framework. (only the information
of
> the view is applied, not the annotations on the properties of the classes)
>
> You mention also the renderer interceptor. But standard this renderer is
> only hit for any editableValueHolder( like input fields or drop downs).
> Since those are the type of components we are interested in ( in doing the
> validation).
> The labels aren't treated at this moment (see processComponent method in
> AbstractValidationInterceptor) so you should write a custom renderer
> interceptor to achieve it.
>
> Your requirements is already on my development list (as an add-on) for a
> few
> months now but had not the time to start with it.
>
> So you need to create (at least) the following items:
> - A custom renderer interceptor for handling the output labels
> - A component initializer that put the * in front of it (caution that it
> isn't done multiple times)
> - The component initializer should search for the referenced component (by
> the for attribute) and do the component initialization of this
> EditableValueHolder. Now the @NotNull is taken into account and the * can
> be placed.
>
> You can also look at the Trinidad support module
>
>
http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component
-support/trinidad-support
> .
> It has a label that is capable of putting a * behind the text so it is
> possible that there is already the kind of solution to your problem. You
> need to port it then only to the standard JSF (or use Trinidad in your
> project).
>
> Regards
> Rudy
>
> On 26 April 2010 14:57, <my...@arcor.de> wrote:
>
> > Hi there,
> >
> > I've found some information at
> > http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc, that it is
> > possible to mark components who require a value via a component
> initializer.
> > In addition I would like to use bean validation and to annotate a class'
> > attributes and mark the input field or even the label of the input
field:
> >
> > 1. @NotNull for an attribute let's say "name"
> > 2. Having an output label referencing an input field
> > 3. Marking all labels referencing to required fields with a '*'
resulting
> > in "*name"
> >
> > I also found the renderer interceptor which seems to be a better choice
> for
> > me, since I want to manipulate the rendering of the label rather than
the
> > input component.
> >
> > Any suggestions?
> >
> > Thanks.
> >
Re: ExtVal: Rendering component with visual indication for required
fields
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
short addition:
basically it depends on the component lib you are using.
e.g. myfaces trinidad supports such indicators out-of-the-box (also based on
meta-data - e.g. in combination with extval).
-> extval + trinidad -> no additional effort.
without trinidad you have to implement a small add-on for extval.
you can have a look at [1]. you just have to replace the trinidad specific
parts and you have to add the indicator on your own (depending on the found
meta-data).
e.g.: instead of using coreOutputLabel at:
ExtValUtils.configureComponentWithMetaData(facesContext, coreOutputLabel,
metaDataResult);
you could use the targetComponent (= the input component). after this call
you can check if the targetComponent is required.
so you keep the compatibility with the required attribute of the component
and you can re-use the existing implementation of extval.
if you are allowed to donate the add-on, i would commit it to os890 (after
reviewing it).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support/src/main/java/org/apache/myfaces/extensions/validator/trinidad/interceptor/TrinidadRendererInterceptor.java
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/4/26 Rudy De Busscher <rd...@gmail.com>
> hello,
>
> The main issue with your requirement is that at the time of the rendering
> of
> the outputlabel, the input text isn't treated yet (because the label is
> most
> of the time in front of the input field). So the required property of the
> input field isn't set yet by the extval framework. (only the information of
> the view is applied, not the annotations on the properties of the classes)
>
> You mention also the renderer interceptor. But standard this renderer is
> only hit for any editableValueHolder( like input fields or drop downs).
> Since those are the type of components we are interested in ( in doing the
> validation).
> The labels aren't treated at this moment (see processComponent method in
> AbstractValidationInterceptor) so you should write a custom renderer
> interceptor to achieve it.
>
> Your requirements is already on my development list (as an add-on) for a
> few
> months now but had not the time to start with it.
>
> So you need to create (at least) the following items:
> - A custom renderer interceptor for handling the output labels
> - A component initializer that put the * in front of it (caution that it
> isn't done multiple times)
> - The component initializer should search for the referenced component (by
> the for attribute) and do the component initialization of this
> EditableValueHolder. Now the @NotNull is taken into account and the * can
> be placed.
>
> You can also look at the Trinidad support module
>
> http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/component-support/trinidad-support
> .
> It has a label that is capable of putting a * behind the text so it is
> possible that there is already the kind of solution to your problem. You
> need to port it then only to the standard JSF (or use Trinidad in your
> project).
>
> Regards
> Rudy
>
> On 26 April 2010 14:57, <my...@arcor.de> wrote:
>
> > Hi there,
> >
> > I've found some information at
> > http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc, that it is
> > possible to mark components who require a value via a component
> initializer.
> > In addition I would like to use bean validation and to annotate a class'
> > attributes and mark the input field or even the label of the input field:
> >
> > 1. @NotNull for an attribute let's say "name"
> > 2. Having an output label referencing an input field
> > 3. Marking all labels referencing to required fields with a '*' resulting
> > in "*name"
> >
> > I also found the renderer interceptor which seems to be a better choice
> for
> > me, since I want to manipulate the rendering of the label rather than the
> > input component.
> >
> > Any suggestions?
> >
> > Thanks.
> >
> > Traumziele - von Beschreibung bis Buchung jetzt kompakt auf den
> > Reise-Seiten von Arcor.de! http://www.arcor.de/rd/footer.reise
> >
>