Mailing-List: contact commits-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tapestry.apache.org
Message-ID: <1518697940.1239828315235.JavaMail.jira@brutus>
Date: Wed, 15 Apr 2009 13:45:15 -0700 (PDT)
From: "Howard M. Lewis Ship (JIRA)" <jira@apache.org>
To: commits@tapestry.apache.org
Subject: [jira] Commented: (TAP5-587) Ajax update of volatile Loop in Zone
 in Form causes issues on Form submit
In-Reply-To: <2140074638.1237526090739.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/TAP5-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699371#action_12699371 ] 

Howard M. Lewis Ship commented on TAP5-587:
-------------------------------------------

The FormInjector was designed for this purpose, to allow Zone behavior when inside a Form (which requires a lot of interaction with the Form).

> Ajax update of volatile Loop in Zone in Form causes issues on Form submit
> -------------------------------------------------------------------------
>
>                 Key: TAP5-587
>                 URL: https://issues.apache.org/jira/browse/TAP5-587
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2
>            Reporter: Joost Schouten
>
> When a volatile Loop in a form gets updated through Ajax and results in having less source items than on initial page render, a  java.util.NoSuchElementException (see below) because the Loop seems to think there are more source items then there are. The whole volatile setting on a loop is kind of unclear to me but I suspect it is intended for a Loop in a form that holds Form Input. In my usecase the Form is just to display non-form data. If my assumption is correct, I miss a parameter on the form like noFormDataLoop, to tell the loop to ignore the complete Loop for state saving.
> When I add if(iterator.hasNext()) to the advanceVolatile() method like below, my usecase works again. I am unsure however if this would interfere with other usecases. All unit tests still work which gives me hope this simple solution might be included.
> private void advanceVolatile()
>     {
>     	if(iterator.hasNext())
>     		value = iterator.next();
>         startHeartbeat();
>     }
> I would love to get some input on if my assumptions are right and if my proposed solutions might work. If so, I'll go ahead and build a patch.
> Cheers,
> Joost
> --------- the exception on Form submit with volatile=true on Loop and Loop item substraction through AJAX --------------
> Caused by: java.util.NoSuchElementException
>        at java.util.AbstractList$Itr.next(AbstractList.java:427)
>        at org.apache.tapestry5.corelib.components.Loop.advanceVolatile(Loop.java:335)
>        at org.apache.tapestry5.corelib.components.Loop.access$200(Loop.java:41)
>        at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:92)
>        at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:96)
>        at org.apache.tapestry5.corelib.components.Form.executeStoredActions(Form.java:471)
>        ... 81 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.