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. > > >> > > > > >
