hi, i agree with werner. furthermore, it will be possible with myfaces extval :)
regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/9/22 Leonardo Uribe <[email protected]> > > > 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 >> >> >
