2009/9/21 Werner Punz <[email protected]> > Leonardo Uribe schrieb: > > Hi >> >> Checking some stuff on the spec and reading some javadoc I have notice >> that it is not possible to make bean validation api available on jsp world, >> because there is no integration point where the default validators are >> created and set to every EditableValueHolder instance. >> >> In jsf 2.0 spec section 3.5.3 Validation Registration says this: >> >> /"....The default validators are appended after any locally defined >> validators once the EditableValueHolder is populated and added to the >> component tree. See the javadocs for UIInput.encodeEnd() for the normative >> specification. A default validator must not be added to a UIInput if a >> validator having the same id is already present....."/ >> >> First note that UIInput.encodeEnd() method does not exists! >> >> In jsp, the only point where we can put code to make the previous >> description work is UIComponentClassicTagBase.doEndTag(). But looking the >> documentation, all jsf related jsp base tag classes has no changes (right >> now myfaces adds default validators on UIInput.validateValue(), but since >> this is not on the spec javadoc, we should change this code). >> >> In previous comments about why @Listener annotation set on a renderer >> class does not work in jsp (because Application.createComponent(String >> componentType) does not scan annotations on renderer classes and to make >> this work we need UIComponentELTag and UIComponentTag call >> Application.createComponent(FacesContext context, String componentType, >> String rendererType) ), the conclusion was annotation api will work only >> partially in jsf 2.0, because changes in jsf related jsp tag classes will >> not be done. >> >> To prove my assumption, I checked the jsp javadoc of f:validateBean, >> looking if exists a jsp tag class for it, like I did to check if really >> f:viewParam does exist in jsp or not. The javadoc points to class >> com.sun.faces.taglib.jsf_core.BeanValidatorTag and again this class does not >> exists. >> >> I would like to know from the new features, which ones are in facelets are >> not in jsp (at the scope of the spec). My personal and maybe incomplete list >> is this: >> >> - composite components >> - bean validation api (by previous arguments) >> - f:event (the javadoc says so) >> - h:outputScript and h:outputStylesheet (requires @Listener annotation >> work in Renderer classes) >> - f:ajax (if we don't have h:outputScript we can't have f:ajax in jsp). >> This makes client behavior api only available on facelets. >> - f:metadata, f:viewParam >> >> I think the eg has stated somewhere in the spec that any new feature > is limited to facelets jsp is seen as legacy technology > which is still dragged around, but nothing more. > > I haven't found that part on the spec yet, but it seems you're right. Looking the spec, f:validateBean is not mentioned on chapter 9 Integration with JSP, but it is on chapter 10 Facelets and its use in Web Applications. Anyway, there is an error on ri jsp taglibdoc that needs to be solved like with f:viewParam. Also, we need to fix our code to not include this tag on our taglibdoc.
Now it is clear that we can move the code related to register default validators to org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate, because this is the right place where the EditableValueHolder is populated and added to the component tree, and this delegate tag handler "wraps" all component tag handlers which could implement EditableValueHolder interface. regards Leonardo Uribe > Werner > >
