Good luck on doing that outside of a JSF UI tag - you may want to consider biting the bullet and writing your own tag.
I had looked into something very similar recently (just to apply an error style class to the prompt / output label if there was an error on the field - I hear something like that may be coming in 1.2?) and found that outside of a tag, it doesn't appear easy to find another component's clientId by it's local id... If you're outside of a tag/UIComponent yourself and don't care about the overhead of searching from the View root each time you need to find another component and it's full client id from just the local id, you THEORETICALLY could do something like the following: String clientId = FacesContext.getCurrentContext().getViewRoot().findComponent("myOtherInp utsName"); In theory that would search from the view root (top level UI component in the current view) all the way down the View component tree until it found a component with that local name/id. But I couldn't get it to work (always returned null) in a trial/prototype (with RI 1.0 and I think 1.1 - I didn't try it with MyFaces yet). I believe the problem may be related to a KnownBug listing in the 1.1 release notes which says that h:outputLabel only works in the same form as the tag its referencing - there appears to be a bug in the recursive searching where the findComponent was only searching one level deep from the UIComponent its executed from. When I tried doing the recursive search code myself ( getting the view root and then recursively checking the current UIComponent's ID against the name/id I'm looking for and if not a match and it is a naming container then get its children and walk them), I DID get it to work, sort of: - I was then able to find the right clientId for each ID/local name I searched for. BUT!!! When my code that called FacesContext.getMessages(clientId), and then walked the messages if any, started working and changing my prompt styleClass to the errorClass, (ie, started returning messages for any fields that had messages >= errors), then my h:message tags that were displaying the field errors started acting really weird: - Before/Without getting the messages for a field to set the prompt style, only fields with errors were showing the errors and they were correct. Eg, with 4 input fields and the first 2 have errors, I'd have 2 errors display correctly and no error messages for the other fields. - When getting the messages for a field to set the prompt style works, the h:messages tags (or rather the context's map of messages?) gets confused and suddenly I have 1 more error message being displayed than actually should exist for that form (eg the first is duplicated and the rest shuffle down by one). Eg, with 4 input fields and the first 2 have errors, I'd have 3 errors displayed instead of the 2 that should be displayed. Only the first 2 fields were required, but I was getting Value is required for the first 3 fields (even though only my first 2 fields showed the error Style via my utility code as they should have). So the <h:message for="field3"/> was showing a message that shouldn't have existed... At that point, I gave up on trying to do this via my own utility code, figuring it was an odd behavior issue that I'd triggered with the messages being retrieved twice for each field per view render and I'm waiting til I have the energy to try writing my own outputLabel tag that can take both a styleClass and an errorClass and set the appropriate one based on whether there's any errors (messages) on the associated UIInput specified via the for= attribute. If anybody else has built or modified a label class to do such a thing (that's open source), please let us know... Anybody know whether the JSF1.2 output label will support such a thing itself? Ps: I'd rather be sailing too, but it doesn't pay as well ;^) ********************************** Michael Burati Senior Software Engineer Bowstreet 200 Ames Pond Drive Tewksbury, MA 01876 T 978-863-1512 F 978-863-1555 www.bowstreet.com Get the latest information on Bowstreet's events and web seminars. -----Original Message----- From: IdRatherBeSailing [mailto:[EMAIL PROTECTED] Sent: Friday, May 27, 2005 11:26 AM To: users@myfaces.apache.org Subject: Quickest/Safest way to get clientId from for name in JSF? What's the quickest and safest (works across JSF impls and doesn't depend on an impl-specific mapping of clientId to a local name of a component) to get the clientId of a component from the local name (eg, for="myinputname" value)? If you must know, I'm trying to determine if a field has errors, to do additional display manipulation in addition to the h:message for="name", but if I just call a method from the JSP with that "name" and my code that it calls does FacesContext.getMessages(theInputName) then it doesn't work because the local name of the component doesn't match it's clientId (eg, in the RI the clientId ends up being <formname>:<inputId> such as myform:myemailaddress. Looking at the tag impl for h:message with a specified component name, I can kind of follow what it's doing to eventually turn that for name value into a client ID but other than building my own tag that does the equivalent, what's the easiest (standard) way of getting a clientId from what you would use in a for= attribute, in a Java utility routine like I'm attempting to use (eg, for calling FacesContext.getMessages(clientId) )? __________________________________ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html