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 <rdebussc...@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 <gerhard.petra...@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 <rdebussc...@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. <mynewsgro...@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.petra...@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 > > > > > > > > > > > > > > > >
