You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by SO...@austin.rr.com on 2007/04/12 23:12:54 UTC
forceId warning when using facelets
Don't know if this has been discussed here before...
I am getting warnings that the 'forceId' attribute is not on various
types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText. I
recently ported to facelets and I don't remember seeing this warning
when I was just using myfaces alone.
I saw a work-around, but I am wondering whether I have to do some
additional configuration.
Re: forceId warning when using facelets
Posted by Simon Kitching <si...@rhe.co.nz>.
I agree with your point about scripting being "unobtrusive", ie that
ideally it should transparently "attach" to existing objects to enhance
their behaviour without having to modify the original elements, like
subclassing extends a class without modifying it.
However completely breaking the encapsulation of JSF components to do
that is ugly. Really ugly. If you are enough of a "purist" to care about
implementing javascript in an "unobtrusive" manner then surely you care
enough about encapsulation to not break that unless absolutely
necessary. If the page is not composed of multiple fragments, then the
IDs are stable and can be used as-is without forceId; if the page is
being composed from multiple fragments then using forceId couples these
fragments together (risks id collisions).
A tag like the one I suggest which generates a js variable containing
the clientId of a specified component seems to generally meet your
requirement of "unobtrusive", in that it can be placed in the page
independently of the component it references. And it can be applied to
any component, not just Tomahawk ones.
Styles are a different problem; I agree I cannot see any elegant
solution. One choice is to specify styleClass="id_foo" on the element
and then target the style using the class rather than the id. Not very
nice, but is it any more obtrusive than specifying "forceId" on the JSF
component? And at least styleClass is part of the JSF standard.
Regards,
Simon
Stefan Frank wrote:
> There are some usecases, where it is really, really useful to have a
> definite id on the component and where forceid is needed: eg. if you
> want to use tinyMCE as texteditor on a textfield. Using a defined id is
> the only solution to style different textfields with different
> tinyMCE-Skins.
>
> The onclick-handler and passing this is not a good or even sufficient
> solution to this problem: Remember, that this is still markup, not code,
> and an unobtrusive way of adding behavior to the elements in a dom-tree
> is certainly preferrable to scattering your code over the whole page
> (even if it is generated and "only" javascript) - (eg. see
> http://alistapart.com/articles/behavioralseparation for a discussion of
> unobtrusive javascript)
>
> and unless someone can show up a better way, forceId is currently the
> only way to tie hand-written javascript to jsf-components
>
> therefore +0.8 by me, as it is dirty, but useful sometimes.
>
> cheers
> stf
>
> 2007/4/13, Volker Weber <v.weber@inexso.de <ma...@inexso.de>>:
>
> i revert to +0.5 because im not realy involved in tomahawk.
>
> But if someone try to introduce forceId to tobago he gets my -1.
>
> I still can't see any reason to use this (except user/password fields
> on form based login).
> Regards,
> Volker
>
> 2007/4/13, Volker Weber <v.weber@inexso.de <ma...@inexso.de> >:
> > 2007/4/12, Simon Kitching <simon.kitching@rhe.co.nz
> <ma...@rhe.co.nz>>:
> > > And forceId sucks anyway. I'd like to see it deprecated and
> removed from
> > > Tomahawk completely.
> >
> > +1
> >
> > :-)
> >
> > Regards,
> > Volker
> >
> > >
> > > This is not needed when javascript is invoked from the
> "onclick" of a
> > > component, which is most of the time. Just pass the "this"
> component to
> > > the javascript function and resolve the desired component id
> relative to
> > > the client-id of the component on which the onclick occurred.
> > >
> > > For the other cases, a tag that outputs the client-id of a target
> > > component as a javascript variable is a nicer solution. At
> worst, there
> > > is a collision of javascript variable names but at least that
> doesn't
> > > stuff up the JSF component ids.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > > Mike Kienenberger wrote:
> > > > Probably because facelets detects valid attributes by looking
> for a
> > > > concrete getter.
> > > >
> > > > ForceId is implemented as a generic getter, so facelets will
> never be
> > > > able to find a "getForceId()" method on a component. You
> can ignore
> > > > the warning as facelets will just set/get using the generic
> method
> > > > when the concrete method fails. Maybe some point down the
> road it
> > > > might be worthwhile to see facelet taglib files identify these
> > > > "hidden" attributes, but functionally, it'll work just fine
> as is.
> > > > Having to add these to the taglib files starts to make it too
> much
> > > > like jsp busywork :-)
> > > >
> > > > On 4/12/07, SOSELLA@austin.rr.com
> <ma...@austin.rr.com> <SOSELLA@austin.rr.com
> <ma...@austin.rr.com>> wrote:
> > > >> Don't know if this has been discussed here before...
> > > >>
> > > >> I am getting warnings that the 'forceId' attribute is not on
> various
> > > >> types, e.g.,
> org.apache.myfaces.component.html.ext.HtmlInputText. I
> > > >> recently ported to facelets and I don't remember seeing this
> warning
> > > >> when I was just using myfaces alone.
> > > >>
> > > >> I saw a work-around, but I am wondering whether I have to do
> some
> > > >> additional configuration.
> > > >>
> > >
> > >
> >
>
>
Re: forceId warning when using facelets
Posted by Volker Weber <v....@inexso.de>.
Hi,
forceId is not needed to get defined ids on the html elements.
if you set a id to each namingContainer tag, and to the relevant tag,
you will get defined ids.
any other usecase?
Regards,
Volker
2007/4/13, Stefan Frank <s....@vierundsechzig.de>:
> There are some usecases, where it is really, really useful to have a
> definite id on the component and where forceid is needed: eg. if you want to
> use tinyMCE as texteditor on a textfield. Using a defined id is the only
> solution to style different textfields with different tinyMCE-Skins.
>
> The onclick-handler and passing this is not a good or even sufficient
> solution to this problem: Remember, that this is still markup, not code, and
> an unobtrusive way of adding behavior to the elements in a dom-tree is
> certainly preferrable to scattering your code over the whole page (even if
> it is generated and "only" javascript) - (eg. see
> http://alistapart.com/articles/behavioralseparation for a
> discussion of unobtrusive javascript)
>
> and unless someone can show up a better way, forceId is currently the only
> way to tie hand-written javascript to jsf-components
>
> therefore +0.8 by me, as it is dirty, but useful sometimes.
>
> cheers
> stf
>
>
> 2007/4/13, Volker Weber <v....@inexso.de>:
> > i revert to +0.5 because im not realy involved in tomahawk.
> >
> > But if someone try to introduce forceId to tobago he gets my -1.
> >
> > I still can't see any reason to use this (except user/password fields
> > on form based login).
> > Regards,
> > Volker
> >
> > 2007/4/13, Volker Weber <v.weber@inexso.de >:
> > > 2007/4/12, Simon Kitching <si...@rhe.co.nz>:
> > > > And forceId sucks anyway. I'd like to see it deprecated and removed
> from
> > > > Tomahawk completely.
> > >
> > > +1
> > >
> > > :-)
> > >
> > > Regards,
> > > Volker
> > >
> > > >
> > > > This is not needed when javascript is invoked from the "onclick" of a
> > > > component, which is most of the time. Just pass the "this" component
> to
> > > > the javascript function and resolve the desired component id relative
> to
> > > > the client-id of the component on which the onclick occurred.
> > > >
> > > > For the other cases, a tag that outputs the client-id of a target
> > > > component as a javascript variable is a nicer solution. At worst,
> there
> > > > is a collision of javascript variable names but at least that doesn't
> > > > stuff up the JSF component ids.
> > > >
> > > > Regards,
> > > >
> > > > Simon
> > > >
> > > > Mike Kienenberger wrote:
> > > > > Probably because facelets detects valid attributes by looking for a
> > > > > concrete getter.
> > > > >
> > > > > ForceId is implemented as a generic getter, so facelets will never
> be
> > > > > able to find a "getForceId()" method on a component. You can
> ignore
> > > > > the warning as facelets will just set/get using the generic method
> > > > > when the concrete method fails. Maybe some point down the road it
> > > > > might be worthwhile to see facelet taglib files identify these
> > > > > "hidden" attributes, but functionally, it'll work just fine as is.
> > > > > Having to add these to the taglib files starts to make it too much
> > > > > like jsp busywork :-)
> > > > >
> > > > > On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> > > > >> Don't know if this has been discussed here before...
> > > > >>
> > > > >> I am getting warnings that the 'forceId' attribute is not on
> various
> > > > >> types, e.g.,
> org.apache.myfaces.component.html.ext.HtmlInputText. I
> > > > >> recently ported to facelets and I don't remember seeing this
> warning
> > > > >> when I was just using myfaces alone.
> > > > >>
> > > > >> I saw a work-around, but I am wondering whether I have to do some
> > > > >> additional configuration.
> > > > >>
> > > >
> > > >
> > >
> >
>
>
Re: forceId warning when using facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
You only have to bind components that you're actually going to use as
addMessage targets. In my experience, that happens infrequently
since most of the time the messages are generated by a validator or
converter.
And as I said, another approach is using findComponent instead of
explicitly binding.
If you hardcode the id in your java code, then you risk
synchronization errors if the id name changes in one place but not in
the other.
On 4/13/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> I tried looking into this approach of having a binding component in the
> backing bean, but that seems *highly* onerous. I would need a binding
> component for nearly every input control. I prefer using the forceId
> approach.
>
>
> ----- Original Message -----
> From: Mike Kienenberger <mk...@gmail.com>
> Date: Friday, April 13, 2007 9:09 am
> Subject: Re: forceId warning when using facelets
> To: MyFaces Discussion <us...@myfaces.apache.org>
>
> > For addMessage, you need to provide
> >
> > component.getClientId(FacesContext.getCurrentInstance())
> >
> > You can either explicitly bind the component to your backing bean so
> > you have a reference to it, or you can use a findComponent method.
> >
> >
> > On 4/13/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> > > There are two reasons why I am using forceId, but both of them are
> > > probably because I am not doing something correctly.
> > >
> > > 1) When I use an addMessage(id, ...) I have to specify the id of the
> > > control for the message is intended. It seems (maybe I am wrong)
> > that> if I don't use forceId, the id used in JSF isn't the same as
> > that> referred to in the addMessage().
> > >
> > > 2) I am using ajax4jsf and I was getting lots of duplicate id's.
> > When I
> > > used forceId, those errors disappeared.
> > >
> > > Maybe there are better ways to avoid these issues, but forceId
> > worked> for me.
> > >
> >
>
Re: forceId warning when using facelets
Posted by SO...@austin.rr.com.
I tried looking into this approach of having a binding component in the
backing bean, but that seems *highly* onerous. I would need a binding
component for nearly every input control. I prefer using the forceId
approach.
----- Original Message -----
From: Mike Kienenberger <mk...@gmail.com>
Date: Friday, April 13, 2007 9:09 am
Subject: Re: forceId warning when using facelets
To: MyFaces Discussion <us...@myfaces.apache.org>
> For addMessage, you need to provide
>
> component.getClientId(FacesContext.getCurrentInstance())
>
> You can either explicitly bind the component to your backing bean so
> you have a reference to it, or you can use a findComponent method.
>
>
> On 4/13/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> > There are two reasons why I am using forceId, but both of them are
> > probably because I am not doing something correctly.
> >
> > 1) When I use an addMessage(id, ...) I have to specify the id of the
> > control for the message is intended. It seems (maybe I am wrong)
> that> if I don't use forceId, the id used in JSF isn't the same as
> that> referred to in the addMessage().
> >
> > 2) I am using ajax4jsf and I was getting lots of duplicate id's.
> When I
> > used forceId, those errors disappeared.
> >
> > Maybe there are better ways to avoid these issues, but forceId
> worked> for me.
> >
>
Re: forceId warning when using facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
For addMessage, you need to provide
component.getClientId(FacesContext.getCurrentInstance())
You can either explicitly bind the component to your backing bean so
you have a reference to it, or you can use a findComponent method.
On 4/13/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> There are two reasons why I am using forceId, but both of them are
> probably because I am not doing something correctly.
>
> 1) When I use an addMessage(id, ...) I have to specify the id of the
> control for the message is intended. It seems (maybe I am wrong) that
> if I don't use forceId, the id used in JSF isn't the same as that
> referred to in the addMessage().
>
> 2) I am using ajax4jsf and I was getting lots of duplicate id's. When I
> used forceId, those errors disappeared.
>
> Maybe there are better ways to avoid these issues, but forceId worked
> for me.
>
Re: forceId warning when using facelets
Posted by SO...@austin.rr.com.
There are two reasons why I am using forceId, but both of them are
probably because I am not doing something correctly.
1) When I use an addMessage(id, ...) I have to specify the id of the
control for the message is intended. It seems (maybe I am wrong) that
if I don't use forceId, the id used in JSF isn't the same as that
referred to in the addMessage().
2) I am using ajax4jsf and I was getting lots of duplicate id's. When I
used forceId, those errors disappeared.
Maybe there are better ways to avoid these issues, but forceId worked
for me.
Re: forceId warning when using facelets
Posted by Stefan Frank <s....@vierundsechzig.de>.
There are some usecases, where it is really, really useful to have a
definite id on the component and where forceid is needed: eg. if you want to
use tinyMCE as texteditor on a textfield. Using a defined id is the only
solution to style different textfields with different tinyMCE-Skins.
The onclick-handler and passing this is not a good or even sufficient
solution to this problem: Remember, that this is still markup, not code, and
an unobtrusive way of adding behavior to the elements in a dom-tree is
certainly preferrable to scattering your code over the whole page (even if
it is generated and "only" javascript) - (eg. see
http://alistapart.com/articles/behavioralseparation for a discussion of
unobtrusive javascript)
and unless someone can show up a better way, forceId is currently the only
way to tie hand-written javascript to jsf-components
therefore +0.8 by me, as it is dirty, but useful sometimes.
cheers
stf
2007/4/13, Volker Weber <v....@inexso.de>:
>
> i revert to +0.5 because im not realy involved in tomahawk.
>
> But if someone try to introduce forceId to tobago he gets my -1.
>
> I still can't see any reason to use this (except user/password fields
> on form based login).
> Regards,
> Volker
>
> 2007/4/13, Volker Weber <v....@inexso.de>:
> > 2007/4/12, Simon Kitching <si...@rhe.co.nz>:
> > > And forceId sucks anyway. I'd like to see it deprecated and removed
> from
> > > Tomahawk completely.
> >
> > +1
> >
> > :-)
> >
> > Regards,
> > Volker
> >
> > >
> > > This is not needed when javascript is invoked from the "onclick" of a
> > > component, which is most of the time. Just pass the "this" component
> to
> > > the javascript function and resolve the desired component id relative
> to
> > > the client-id of the component on which the onclick occurred.
> > >
> > > For the other cases, a tag that outputs the client-id of a target
> > > component as a javascript variable is a nicer solution. At worst,
> there
> > > is a collision of javascript variable names but at least that doesn't
> > > stuff up the JSF component ids.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > > Mike Kienenberger wrote:
> > > > Probably because facelets detects valid attributes by looking for a
> > > > concrete getter.
> > > >
> > > > ForceId is implemented as a generic getter, so facelets will never
> be
> > > > able to find a "getForceId()" method on a component. You can
> ignore
> > > > the warning as facelets will just set/get using the generic method
> > > > when the concrete method fails. Maybe some point down the road it
> > > > might be worthwhile to see facelet taglib files identify these
> > > > "hidden" attributes, but functionally, it'll work just fine as is.
> > > > Having to add these to the taglib files starts to make it too much
> > > > like jsp busywork :-)
> > > >
> > > > On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> > > >> Don't know if this has been discussed here before...
> > > >>
> > > >> I am getting warnings that the 'forceId' attribute is not on
> various
> > > >> types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText
> . I
> > > >> recently ported to facelets and I don't remember seeing this
> warning
> > > >> when I was just using myfaces alone.
> > > >>
> > > >> I saw a work-around, but I am wondering whether I have to do some
> > > >> additional configuration.
> > > >>
> > >
> > >
> >
>
Re: forceId warning when using facelets
Posted by Volker Weber <v....@inexso.de>.
i revert to +0.5 because im not realy involved in tomahawk.
But if someone try to introduce forceId to tobago he gets my -1.
I still can't see any reason to use this (except user/password fields
on form based login).
Regards,
Volker
2007/4/13, Volker Weber <v....@inexso.de>:
> 2007/4/12, Simon Kitching <si...@rhe.co.nz>:
> > And forceId sucks anyway. I'd like to see it deprecated and removed from
> > Tomahawk completely.
>
> +1
>
> :-)
>
> Regards,
> Volker
>
> >
> > This is not needed when javascript is invoked from the "onclick" of a
> > component, which is most of the time. Just pass the "this" component to
> > the javascript function and resolve the desired component id relative to
> > the client-id of the component on which the onclick occurred.
> >
> > For the other cases, a tag that outputs the client-id of a target
> > component as a javascript variable is a nicer solution. At worst, there
> > is a collision of javascript variable names but at least that doesn't
> > stuff up the JSF component ids.
> >
> > Regards,
> >
> > Simon
> >
> > Mike Kienenberger wrote:
> > > Probably because facelets detects valid attributes by looking for a
> > > concrete getter.
> > >
> > > ForceId is implemented as a generic getter, so facelets will never be
> > > able to find a "getForceId()" method on a component. You can ignore
> > > the warning as facelets will just set/get using the generic method
> > > when the concrete method fails. Maybe some point down the road it
> > > might be worthwhile to see facelet taglib files identify these
> > > "hidden" attributes, but functionally, it'll work just fine as is.
> > > Having to add these to the taglib files starts to make it too much
> > > like jsp busywork :-)
> > >
> > > On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> > >> Don't know if this has been discussed here before...
> > >>
> > >> I am getting warnings that the 'forceId' attribute is not on various
> > >> types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText. I
> > >> recently ported to facelets and I don't remember seeing this warning
> > >> when I was just using myfaces alone.
> > >>
> > >> I saw a work-around, but I am wondering whether I have to do some
> > >> additional configuration.
> > >>
> >
> >
>
Re: forceId warning when using facelets
Posted by Volker Weber <v....@inexso.de>.
2007/4/12, Simon Kitching <si...@rhe.co.nz>:
> And forceId sucks anyway. I'd like to see it deprecated and removed from
> Tomahawk completely.
+1
:-)
Regards,
Volker
>
> This is not needed when javascript is invoked from the "onclick" of a
> component, which is most of the time. Just pass the "this" component to
> the javascript function and resolve the desired component id relative to
> the client-id of the component on which the onclick occurred.
>
> For the other cases, a tag that outputs the client-id of a target
> component as a javascript variable is a nicer solution. At worst, there
> is a collision of javascript variable names but at least that doesn't
> stuff up the JSF component ids.
>
> Regards,
>
> Simon
>
> Mike Kienenberger wrote:
> > Probably because facelets detects valid attributes by looking for a
> > concrete getter.
> >
> > ForceId is implemented as a generic getter, so facelets will never be
> > able to find a "getForceId()" method on a component. You can ignore
> > the warning as facelets will just set/get using the generic method
> > when the concrete method fails. Maybe some point down the road it
> > might be worthwhile to see facelet taglib files identify these
> > "hidden" attributes, but functionally, it'll work just fine as is.
> > Having to add these to the taglib files starts to make it too much
> > like jsp busywork :-)
> >
> > On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> >> Don't know if this has been discussed here before...
> >>
> >> I am getting warnings that the 'forceId' attribute is not on various
> >> types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText. I
> >> recently ported to facelets and I don't remember seeing this warning
> >> when I was just using myfaces alone.
> >>
> >> I saw a work-around, but I am wondering whether I have to do some
> >> additional configuration.
> >>
>
>
Re: forceId warning when using facelets
Posted by Simon Kitching <si...@rhe.co.nz>.
And forceId sucks anyway. I'd like to see it deprecated and removed from
Tomahawk completely.
This is not needed when javascript is invoked from the "onclick" of a
component, which is most of the time. Just pass the "this" component to
the javascript function and resolve the desired component id relative to
the client-id of the component on which the onclick occurred.
For the other cases, a tag that outputs the client-id of a target
component as a javascript variable is a nicer solution. At worst, there
is a collision of javascript variable names but at least that doesn't
stuff up the JSF component ids.
Regards,
Simon
Mike Kienenberger wrote:
> Probably because facelets detects valid attributes by looking for a
> concrete getter.
>
> ForceId is implemented as a generic getter, so facelets will never be
> able to find a "getForceId()" method on a component. You can ignore
> the warning as facelets will just set/get using the generic method
> when the concrete method fails. Maybe some point down the road it
> might be worthwhile to see facelet taglib files identify these
> "hidden" attributes, but functionally, it'll work just fine as is.
> Having to add these to the taglib files starts to make it too much
> like jsp busywork :-)
>
> On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
>> Don't know if this has been discussed here before...
>>
>> I am getting warnings that the 'forceId' attribute is not on various
>> types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText. I
>> recently ported to facelets and I don't remember seeing this warning
>> when I was just using myfaces alone.
>>
>> I saw a work-around, but I am wondering whether I have to do some
>> additional configuration.
>>
Re: forceId warning when using facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
Probably because facelets detects valid attributes by looking for a
concrete getter.
ForceId is implemented as a generic getter, so facelets will never be
able to find a "getForceId()" method on a component. You can ignore
the warning as facelets will just set/get using the generic method
when the concrete method fails. Maybe some point down the road it
might be worthwhile to see facelet taglib files identify these
"hidden" attributes, but functionally, it'll work just fine as is.
Having to add these to the taglib files starts to make it too much
like jsp busywork :-)
On 4/12/07, SOSELLA@austin.rr.com <SO...@austin.rr.com> wrote:
> Don't know if this has been discussed here before...
>
> I am getting warnings that the 'forceId' attribute is not on various
> types, e.g., org.apache.myfaces.component.html.ext.HtmlInputText. I
> recently ported to facelets and I don't remember seeing this warning
> when I was just using myfaces alone.
>
> I saw a work-around, but I am wondering whether I have to do some
> additional configuration.
>