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