9

Situation

JavaServer Faces Version: 2.1.6

I got a parent composite component with two nested cc. One of them contains a HtmlPanelGroup, which has a component binding. I use that binding to programmatically add HtmlCommandLink-Objects to the HtmlPanelGroup.

Let's call some IDs:

  • PARENT for the parent cc
  • CHILD_FIRST for the first child cc, nested in PARENT
  • CHILD_SECOND for the second child cc, nested in PARENT
  • GROUP for the PanelGroup, nested in CHILD_SECOND
  • LINK_1 for the first HtmlCommandLink-Object, progammatically added to GROUP

Expectation

I expect the following ID Chaining (with default javax.faces.SEPARATOR_CHAR):

PARENT (Composite Component, declarative)
  PARENT:CHILD_FIRST (Composite Component, declarative)
  PARENT:CHILD_SECOND (Component Component, declarative)
    PARENT:CHILD_SECOND:GROUP (HtmlPanelGroup, declarative)
      PARENT:CHILD_SECOND:GROUP:LINK_1 (HtmlCommandLink, programmatically)

Problem

The ID of the HtmlCommandLink-Object is wrong at the first page visit. Instead of "PARENT:CHILD_SECOND:GROUP:LINK_1" the ID is only "CHILD_SECOND:GROUP:LINK_1". After I refresh the page the ID is correctly "PARENT:CHILD_SECOND:GROUP:LINK_1". In fact every component in the second composite component ("CHILD_SECOND") is missing the first part of the ID ("PARENT"). After refresh all IDs are correctly.

Solution

I might automatically refresh the page after the first visit. But I don't want to.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
FeHe
  • 156
  • 8
  • 5
    I find it hard to understand the concrete problem because `HtmlPanelGroup` is not an `NamingContainer` component and is therefore not supposed to prepend its ID to command link children. You should not be seeing `GROUP:` in the ID of the command link children at all. A real SSCCE would tremendously help in understanding the concrete problem better. – BalusC Apr 17 '13 at 15:02
  • Why in earth does this question have 10 upvotes? The question is in its current form without a valid SSCCE not making any sense, and therefore not answerable. Too bad that I can't re-cast an expired close vote. – BalusC Aug 21 '13 at 15:16
  • @Bluasc I think you are right this is difficult to figure out actual PanelGroup is containing the component or not. – Sheel Feb 25 '14 at 12:29

1 Answers1

-2

the id after interpreted by the browser doesn't like what you thought. as far as i know it doesn't exceed 3 levels. For example:

 <h:form id="form">
    <h:panel id="panel">
        <h:panel id="panel1">
            <h:label id="lab"/>
        </h:panel>
        <h:panel id="panel2">
        </h:panel>    
    </h:panel>
</h:form>

then the label's id will not be form:panel:panel1:lab but form:panel:lab. if the widget that you want to get the id is more deeper, then i can't tell but it won't exceed 3 levels. i can tell you how to find the id. you can just write the page, and then view it on the chrome or firefox where you can see the source code after interpreted. so you can get the id you want.

good luck!

chero
  • 13
  • 2
  • 2
    Why in earth is this answer upvoted? The statement *"as far as i know it doesn't exceed 3 levels"* is pure nonsense. Related learning material: http://stackoverflow.com/questions/8634156/how-to-reference-components-in-jsf-ajax-cannot-find-component-with-identifier/8644762#8644762 Note that the `` is **not** a `NamingContainer`. Your statement that `:panel` would be present in the client ID of `` is therefore another pure nonsense. – BalusC Aug 21 '13 at 15:15