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