[JAVASERVERFACES-1527] Facelets: Duplicate lclient Ids for components 'stamped' by c:ForEach Created: 28/Jan/10  Updated: 22/Oct/13  Resolved: 29/Jul/10

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.0.1
Fix Version/s: 2.1_gf31_m4

Type: Bug Priority: Major
Reporter: mst_70 Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Text File foreach.diff    
Issue Links:
Related
is related to JAVASERVERFACES-2188 c:forEach overrides ID's of children ... Closed
is related to JAVASERVERFACES-2548 ids cannot be set within a c:forEach Closed
Issuezilla Id: 1,527
Status Whiteboard:

size_medium importance_large


 Description   

If you repeat a component with c:forEach in Facelets, the current implementation
does not ensure that component's client Id is unique when Id is supplied as a
literal. Consider the following example:

<c:forEach var="person" items="$

{people.people}

">
<h:inputText id="item1" value=#

{person.name}

/>
</c:forEach>

This will produce duplicate client Ids with Facelets, but not with JSP.
If the id attribute is not specified, the unique Ids are generated.
While I understand that specifying literal Ids on the stamped components appears
to be a corner case (the client Ids will be impossible to predict anyways), we
have a real use case where component's Id attribute is used for integration with
an external content customization solution.



 Comments   
Comment by mst_70 [ 28/Jan/10 ]

Created an attachment (id=1084)
Patch for auto-generating Ids after the first stamped component

Comment by Ryan Lubke [ 02/Feb/10 ]

Update target milestone.

Comment by Ed Burns [ 01/Jun/10 ]

ADF keywords

Comment by Ed Burns [ 03/Jun/10 ]

keywords separated by spaces

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 11/Jun/10 ]

rogerk not roger

Comment by rogerk [ 24/Jun/10 ]

importance_large

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m4

Comment by Ed Burns [ 28/Jun/10 ]

Target for GlassFish 3.1 M4

Comment by rogerk [ 27/Jul/10 ]

starting

Comment by rogerk [ 28/Jul/10 ]

Created an attachment (id=1215)
Changes

Comment by josefreire [ 28/Jul/10 ]

Just a heads up.

This issue was identified on the facelets project, and my latest proposed patch
is very simple with very good results.

Please check https://facelets.dev.java.net/issues/show_bug.cgi?id=353, or the
latest proposed patch
https://facelets.dev.java.net/nonav/issues/showattachment.cgi/145/proposedPatch-353-20091229.diff

Thanks.

Comment by rogerk [ 28/Jul/10 ]

Hey thanks Jose,

I'll take a look at your patch as well.
Stay tuned....

-roger

Comment by rogerk [ 28/Jul/10 ]

Hello Jose,

Your patch is really specific to Facelets (pre JSF 2.0 Facelets)..
Things have changed a bit for JSF 2.0 . Can you rework your patch
for JSF 2.0 Facelets? This issue is addressing JSF 2.0.

Comment by josefreire [ 28/Jul/10 ]

Hi Roger,

Sure, I'll give my best shot. I think the approach I took in Facelets 1.1 is
still valid for JSF 2.0.

My first patches seem very similar to your patch. However I've found that with
this approach it broke state saving in some situations (ex: richfaces tree
stopped working correctly with server state saving).

Comment by Ed Burns [ 29/Jul/10 ]

Roger, because you are committing a patch supplied by Stevan, you can
give the r=rogerk yourself. For what it's worth, I have reviewed it as
well and give it r=edburns.

Ed

Comment by rogerk [ 29/Jul/10 ]

checked in.

Comment by josefreire [ 29/Jul/10 ]

Hi everyone,

First a clarification: I confused this bug report with another one that is
present in Facelets 1.1
(https://facelets.dev.java.net/issues/show_bug.cgi?id=353), and it's still
present in JSF 2.0. I'll open a new issue to address it, and I've got a proposed
patch to upload.

Anyway, reading carefully this bug description I don't understand why this was
considered a bug in the first place.

The example code to illustrate the bug clearly forces the h:inputText to have
the same ID, resulting in many h:inputText with the same id in the component
tree, so in my opinion, this is clearly a programming error and the reference
implementation shouldn't be patched to handle this kind of situations.

I think that the real bug here is why it doesn't give a duplicate ID with JSP.

Just my 2 cents...

Comment by kurtz_mr [ 10/Feb/12 ]

Is this fix really going in the right direction? I have

<c:forEach items="#

{widgetController.widgets}

" var="widget">
<ui:include src="#

{widget.path}

">
<ui:param name="widget" value="#

{widget}

"/>
</ui:include>
</c:forEach>

Where I ensure myself ids in included facelets are unique. Too bad framework outsmarts me and replaces my ids with random garbage so I'm unable to do partial updates now.

Comment by Manfred Riem [ 23/Mar/12 ]

Closing resolved issue out

Comment by josefreire [ 26/Apr/12 ]

This "fix" is a major regression and is a showstopper to our upgrade from JSF 1.2.

Issue http://java.net/jira/browse/JAVASERVERFACES-2188 is a clear example on how the effort to make this improvement broke the framework.

This issue should be reopened and a different approach should be considered.

<ui:include> should have some kind of flag to signal the framework to rewrite it's id's, and this should not be the default behaviour.

Comment by josefreire [ 09/May/12 ]

There's a trivial workaround for this issue.

If the user wraps the <ui:include> with <f:subView>, there will be no id clash:

<c:forEach items="#

{controller.list}

" var="itemToInclude">
<f:subView>
<ui:include src="#

{itemToInclude}

" />
</f:subView>
</c:forEach>

The user clearly doesn't require the ids, so a f:subView is a reasonable and easy solution.

Could you please reopen this issue?

Generated at Fri Mar 27 22:57:48 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.