Databases
StackOverflow2013
Postsdbo
PONecessity of setting ID attribute of components in JSF 1.1
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PONecessity of setting ID attribute of components in JSF 1.1
    primarykey
    data
    text
    <p>Disclaimer: I realize that JSF 2.0 exists and am familiar. This question is in regard to <strong>JSF 1.1</strong> under <strong>IBM WebSphere</strong>.</p> <p>I have heard/seen varying degrees of support for the notion that ALL JSF components on a page need to have an ID attribute specified at development time. When I say "ALL" components, I mean everything... including components that are traditionally "output only", e.g., <code>&lt;h:ouputText&gt;</code>, <code>&lt;h:panelGroup&gt;</code>,<code>&lt;h:panelGrid&gt;</code>, etc...</p> <p>This question continually comes up internally, in response to the appearance of "Duplicate Component ID" exceptions in the logs. The components that claim to have duplicate IDs sometimes are JSF-generated IDs, or are IDs of elements that cannot be explicitly set (e.g., elements in a row of a grid with n-number of rows).</p> <p>I'm looking for some objective guidance on what IDs should, could, or need to (or not) be set in regard to the gamut of JSF components.</p> <p>My main concern is two-fold:</p> <ul> <li>retro-actively adding IDs to everything (even things that probably do not need them) in a mad-dash to eliminate any possibility of a duplicate component ID exception occurring may not be the best use of time. </li> <li>the resultant bloat in the HTML stream at run/render-time is just plain ugly, e.g., <code>&lt;span&gt;</code> elements with IDs that add absolutely no constructive value to the page</li> </ul> <p><strong>ADDENDUM:</strong></p> <p>Based on more research and other posts here on SO, I may still be a bit confused. <strong>Which of the following is "correct"?:</strong></p> <p><strong>Method A: <code>&lt;f:subview&gt;</code> Specified in Included Page</strong></p> <pre><code>&lt;%-- parent_page.jsp --%&gt; &lt;html&gt; &lt;f:view&gt; &lt;jsp:include page="included_child_page.jsp" /&gt; &lt;/f:view&gt; &lt;/html&gt; &lt;%-- included_child_page.jsp --%&gt; &lt;f:subview id="myID"&gt; &lt;h:outputText value="Some content here..." /&gt; &lt;/f:subview&gt; </code></pre> <p><strong>Method B: <code>&lt;f:subview&gt;</code> Specified in Including/Parent Page</strong></p> <pre><code>&lt;%-- parent_page.jsp --%&gt; &lt;html&gt; &lt;f:view&gt; &lt;f:subview id="myID"&gt; &lt;jsp:include page="included_child_page.jsp" /&gt; &lt;/f:subview&gt; &lt;/f:view&gt; &lt;/html&gt; &lt;%-- included_child_page.jsp --%&gt; &lt;h:outputText value="Some content here..." /&gt; </code></pre> <p>The overwhelming majority of our JSPs use Method A, above. We routinely get Duplicate Component ID errors from many of these pages. A handful of pages were changed to use Method B. We rarely/never get errors from these pages-- when we do, it's usually from components that render collections (tables/lists) where an arbitrary ID must be generated by the Faces implementation at runtime for a given row or element.</p> <p>From that experience it's been difficult for me to understand which way should work all the time. Which way is <strong>correct</strong>?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USPattMauler
    1. USPattMauler
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PONecessity of setting ID attribute of components in JSF 1.1
      1. USPattMauler
      1. VTBountyStart
    2. VO
      singulars
      1. PONecessity of setting ID attribute of components in JSF 1.1
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PONecessity of setting ID attribute of components in JSF 1.1
      1. This table or related slice is empty.
      1. VTUpMod
    1. CODuplicate component ID errors in JSF 1.x applications on JSP are generally caused by using the `<f:subview>` tag and/or the `binding` attribtue the wrong way. There should be **one** `<f:subview>` with that ID in the entire view (watch out with re-included subviews!) and there should be **one** component bound to the property behind `binding` (watch out with session scoped beans which are shared among multiple views!).
      singulars
      1. PONecessity of setting ID attribute of components in JSF 1.1
      1. USBalusC
    2. COWhat is some empirical guidance on the proper way to use `<f:subview>`, then? Is it safe to say to always/never include the `<f:subview>` tag-pair in the included files themselves? Or is that a matter of preference, performance, or none of the above?
      singulars
      1. PONecessity of setting ID attribute of components in JSF 1.1
      1. USPattMauler
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload