[JAVASERVERFACES-1991] Submitted value of UIInput gets lost inside composite components Created: 15/Mar/11  Updated: 02/Jul/12  Resolved: 27/Jun/12

Status: Closed
Project: javaserverfaces
Component/s: facelets, state saving, validation
Affects Version/s: 2.0.3, 2.0.4, 2.1.0
Fix Version/s: 2.1.11, 2.2.0-m05

Type: Bug Priority: Major
Reporter: Mathias Werlitz Assignee: Ed Burns
Resolution: Cannot Reproduce Votes: 15
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.6, Tomcat 6


Attachments: Text File 20120202-1543-i_mojarra_1991_reproducer.patch     Zip Archive lostSubmittedValue.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES-2040 Partial state saving broken for compo... Closed
Duplicate
duplicates JAVASERVERFACES-1985 PostAddToViewEvent publishing conditi... Closed
Status Whiteboard:

size_large importance_medium

Tags: composite

 Description   

When a UIInput component are nested inside composite components, its submittedValue gets lost and is not rendered on validation errors.

This simple example fails:
<myCC:layout>
<h:inputText>
<f:validateLength minimum="20"/>
</h:inputText>
</myCC:layout>

The issue is present if the composite component inserts its childs with <cc:insertChildren />. When using facets with <cc:renderFacet /> it works correctly.

This issue seems to have a strong relation to JAVASERVERFACES-1825 because the conditions and possible workarounds are very similar.
Both bugs are really blockers. Composite components become useless this way.



 Comments   
Comment by Mathias Werlitz [ 15/Mar/11 ]

The example shows a simple h:inputText and a h:inputText nested inside a very simple composite component.
If you enter a short text into both fields and submit the form, the submitted value of the simple h:inputText is redisplayed and the submitted value of the h:inputText nested inside the composite component is NOT on validation errors.

Comment by tlind [ 24/Mar/11 ]

This seems to be a duplicate of JAVASERVERFACES-1784. I am also experiencing this problem and it basically makes composite components that contain input fields a no-go.

Comment by Mathias Werlitz [ 05/May/11 ]

Well it seems that JAVASERVERFACES-2040 is the root cause of this problem.
My proposed patch will also fix this issue.

Comment by rogerk [ 06/May/11 ]

Ok I am able to duplicate this problem.

Comment by joserodolfo.freitas [ 01/Jun/11 ]

I workaround this problem putting <cc:insertChildren /> inside a h:panelGroup

    <h:panelGroup >        
      <cc:insertChildren/>        
    </h:panelGroup>
Comment by Adrian Gygax [ 25/Aug/11 ]

<ui:fragment> worked for me as well as a workaround with the benefit that it doesn't render any addiontal HTML:

<ui:fragment>        
  <cc:insertChildren/>        
</ui:fragment>
Comment by conpem [ 27/Sep/11 ]

Hi Mathias!
I need help on this issue urgently. you write there is a patch that solves this problem. we are running with 2.0.4_b for now and no plans on upgrading jsf.
I created an issue: http://java.net/jira/browse/JAVASERVERFACES-2216 which regards the same bug about cc:insertChildren and using the wrap h:panelGroup
please if you have time look through it!

Best.

Comment by Ed Burns [ 11/Jan/12 ]

Because a workaround exists, we can downgrade this from blocker status.

Comment by anadollu [ 19/Jan/12 ]

Hi Ed,

Please don't downgrade this issue from blocker, Becouse workaround is not valid for all versions. 2.1.5 version don't work with this workaround. In my opinion, this issue should be considered as blocker.

Thanks.

Comment by Mathias Werlitz [ 29/Jan/12 ]

The problem is that state saving of composite components is broken in Mojarra. I don't understand why this fundamental problem doesn't get fixed. It's already open for 10 months. I explained in detail what goes wrong and supplied a patch for the root cause of the problem JAVASERVERFACES-2040. This will also fix this issue.

Comment by Ed Burns [ 02/Feb/12 ]

Here's the cause of the problem:

On render, we have a new instance for the UIInput inside the CC, whereas
we have the same instance for the UIInput outside the CC.

The workaround, which enables me to de-prioritize this from Blocker to Major, is to use value binding or component binding in the case of the inner component.

I'll continue to work on this as high priority, though.

Comment by Ed Burns [ 02/Feb/12 ]

Believe it or not, the reason this one is a problem is because of our hack approach for the implementation to cc:insertChildren and cc:insertFacet.

It's a duplicate of JAVASERVERFACES-1985.

Comment by Ed Burns [ 02/Feb/12 ]

I don't understand why InsertChildrenHandler.apply() is called once on
the initial render and twice on the postback. That seems incorrect.

Comment by Ed Burns [ 02/Feb/12 ]

I don't understand why InsertChildrenHandler.apply() is called once on
the initial render and twice on the postback. That seems incorrect.

Comment by Mathias Werlitz [ 03/Feb/12 ]

Hi Ed,

yes, JAVASERVERFACES-1985 is the problem here and is part of the problem of JAVASERVERFACES-2040. Please see my analysis of JAVASERVERFACES-2040. InsertChildrenHandler.apply() is added and called twice because the component tree is rebuild a second time before rendering.

My patch for JAVASERVERFACES-2040 will fix (at least a part of) JAVASERVERFACES-1985. It does not remove the "hack approach" but the components will not be recreated and the "listener hack" will only executed once.

Comment by Manfred Riem [ 27/Jun/12 ]

Using the attached example I am unable to reproduce this on 2.1.11

Comment by Mathias Werlitz [ 02/Jul/12 ]

Yes, it seems this issue has been fixed with 2.1.11.

Generated at Thu Aug 27 21:38:07 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.