myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [jsf 2.0] bean validation api will not be available on jsp apps? if this is true why exists in jsp
Date Tue, 22 Sep 2009 06:51:24 GMT
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 <lu4242@gmail.com>

>
>
> 2009/9/21 Werner Punz <werner.punz@gmail.com>
>
> 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
>>
>>
>

Mime
View raw message