Skip to main content

JSF 2.0.2 : Inconsistent use of composite attributes in component fields

5 replies [Last post]
tacitust
Offline
Joined: 2010-02-24

Okay, here's a bit of a puzzle. I thought it was a bug at first, but now I'm wondering if it's a quirk of the spec. Here's the code:

Nothing fancy, just a simple composite component to be used in a form.

The puzzling bit is that I get different results for what gets substituted for the three instances of #{cc.attrs.id} in the implementation.

If cc.attrs.id = "name", I get id="name:name" in the inputText component, but I get for="name" for both the outputLabel and message components, even though I am using exactly the same EL for all three.

Here's the generated HTML:


User Name or Email Address

and here's the Component Tree:

(Here the two for fields are blank, and the id field is the one with the corrrect value of "name". Somehow a copy of "name" is added to all the fields in the final HTML rendering.)

I see in the JavaDoc that inputText id is defined as just a String, whereas the for attribute in the other two elements is a full-blown javax.el.ValueExpression that must result in a string. Is that the reason for the different result?

If so, what do I need to do to get the same value in all three fields -- which is obviously what I need in this particular case? I feel I must be missing something.

Cheers,

Mike

Message was edited by: tacitust

Message was edited by: tacitust

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ed Burns

On 2/25/10 2:40 AM, webtier@javadesktop.org wrote:
> Okay, having done some more reading, it seems that JSF takes it upon itself to generate id
> values (and name values) for components in a composite, which is why I can't set the id on
> the inputText without it being modified.

Yes, this is because composite components are, by necessity, naming
containers.

> But does that mean it's impossible to match a "for" attribute in a label or a message with
> an "id" attribute of an input field? (without some ugly hack like doubling up the supplied
> id in the "for" fields to make them match the value generated in the "id" field. I am sure
> something like that cannot be relied upon in future releases)

Certainly your requirement is already satisfied. You have to do
something like this:

This gets the proper client id for the top level component (either auto
generated, or manually assigned by the page author in the using page).

Ed

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

tacitust
Offline
Joined: 2010-02-24

Thanks for taking the time to answer my questions, Ed. Things are beginning to seem a lot less murky as I work through some examples :-)

tacitust
Offline
Joined: 2010-02-24

Argh -- I should have added that this was on Netbeans 6.8, Mojarra 2.0.2, and Glassfish v3.

tacitust
Offline
Joined: 2010-02-24

Okay, having done some more reading, it seems that JSF takes it upon itself to generate id values (and name values) for components in a composite, which is why I can't set the id on the inputText without it being modified.

But does that mean it's impossible to match a "for" attribute in a label or a message with an "id" attribute of an input field? (without some ugly hack like doubling up the supplied id in the "for" fields to make them match the value generated in the "id" field. I am sure something like that cannot be relied upon in future releases)

It would seem that if I am supplying the id value myself, I should at least have the option of telling JSF not to fiddle with it.

(Or am I still missing something... which is quite likely!)

Ed Burns

On 2/25/10 2:40 AM, webtier@javadesktop.org wrote:
> Okay, having done some more reading, it seems that JSF takes it upon itself to generate id
> values (and name values) for components in a composite, which is why I can't set the id on
> the inputText without it being modified.

Yes, this is because composite components are, by necessity, naming
containers.

> But does that mean it's impossible to match a "for" attribute in a label or a message with
> an "id" attribute of an input field? (without some ugly hack like doubling up the supplied
> id in the "for" fields to make them match the value generated in the "id" field. I am sure
> something like that cannot be relied upon in future releases)

Certainly your requirement is already satisfied. You have to do
something like this:

This gets the proper client id for the top level component (either auto
generated, or manually assigned by the page author in the using page).

Ed

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net