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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED] >: > > 2007/4/12, Simon Kitching <[EMAIL PROTECTED]>: > > > 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. > > > >> > > > > > > > > >
