myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rudy De Busscher <rdebussc...@gmail.com>
Subject Re: ExtVal: Rendering component with visual indication for required fields
Date Wed, 28 Apr 2010 10:00:18 GMT
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 <gerhard.petracek@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 <rdebusscher@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. <mynewsgroups@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>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message