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
