Hello Mike,
Thanks for you suggestion.
Using a fully-qualified client-id does work indeed. It took some
trail-and-error to determine the proper path from the NamingContainer,
but I got a proper reference to the t:selectOneRadio for the
t:radio-tag.
So I started to use the following code:
You're using the same variable name for two different things:
t:selectItems
var=seeker
t:dataList
var=seeker
I wouldn't recommend doing this as it's only going to cause confusion
(even though they are both in different scopes).
I'm guessing the ordering problem is caused by how
Hello Mike,
I'm already using facelets with MyFaces for my application ( who isn't
these days? ), so the suggestion to use a panelGroup isn't necessary.
I followed your advice and changed one of the values of the
var-attribute and that solved the problem. Now I can place the
t:radio-tag before
Wow. I'm surprised that the var value was the cause of the problem. I
don't really know why that would be. Glad it worked out, though.
On 6/5/07, Beelen, Marco [EMAIL PROTECTED] wrote:
Hello Mike,
I'm already using facelets with MyFaces for my application ( who isn't
these days? ), so the
Hello all,
I'm building an application and I don't know how to solve a certain GUI
problem.
Use case: The employee enters an request for a certain seeker ( = a
Customer )
1) The employee searches for the seeker based upon it's name.
2) The employee select the appropreate seeker from the
Your idea of using t:radio was the first thought I had as well. Maybe
if you specify the for as a fully-qualified client-id it will work.
If you don't want to hardcode this, one possibility is to bind the
selectOneRadio to a backing bean and fetch the clientid for that
component as the value
6 matches
Mail list logo
