Re: Wicket-3438 seems to cause issues if a form is removed

[Pedro Santos]

Hi it is a bug, I created https://issues.apache.org/jira/browse/WICKET-3488

On Tue, Mar 1, 2011 at 8:30 AM, Alexander Landsnes Keül <
alexander.landsnes.k...@visma.no> wrote:

> Upgraded to wicket 1.4.16 yesterday, and it seems to cause issues when a
> form is removed after submit. Problem is probably related to the change in
> Wicket-3438 (https://issues.apache.org/jira/browse/WICKET-3438 <
> https://issues.apache.org/jira/browse/WICKET-3438> )
>
>
>
> The usage we have a few places is something like this
>
> onSubmit() {
>
>  updateData();
>
>  replacePanel();
>
> }
>
>
>
> Used to work fine, but looking at Form#process(IFormSubmittingComponent
> submittingComponent)  it first delegates the submit to our button
> implementation, then calls parameters.remove(getHiddenFieldId());
>
> getHiddenFieldId() tries to look up the page to check if it's stateless,
> but as the panel containing the form has been replaced already the form has
> no parent page.
>
>
>
> The only place I've encountered that is in
> parameters.remove(hiddenFieldId); could be solved by retrieving the
> parameter before delegating the submit, and removing the parameter after
> processing is done. Looking at the code it doesn't seem like it would be a
> terribly good idea to remove all the parameters before delegating the
> process, but retrieving it shouldn't be an issue. The rest of the parameter
> cleanup seems to be safe even if the form is removed.
>
>
>
> Alex
>
>


-- 
Pedro Henrique Oliveira dos Santos

Wicket-3438 seems to cause issues if a form is removed

[Alexander Landsnes Keül]

Upgraded to wicket 1.4.16 yesterday, and it seems to cause issues when a form 
is removed after submit. Problem is probably related to the change in 
Wicket-3438 (https://issues.apache.org/jira/browse/WICKET-3438 
 )

 

The usage we have a few places is something like this

onSubmit() {

  updateData();

  replacePanel();

}

 

Used to work fine, but looking at Form#process(IFormSubmittingComponent 
submittingComponent)  it first delegates the submit to our button 
implementation, then calls parameters.remove(getHiddenFieldId()); 

getHiddenFieldId() tries to look up the page to check if it's stateless, but as 
the panel containing the form has been replaced already the form has no parent 
page. 

 

The only place I've encountered that is in parameters.remove(hiddenFieldId); 
could be solved by retrieving the parameter before delegating the submit, and 
removing the parameter after processing is done. Looking at the code it doesn't 
seem like it would be a terribly good idea to remove all the parameters before 
delegating the process, but retrieving it shouldn't be an issue. The rest of 
the parameter cleanup seems to be safe even if the form is removed.

 

Alex