Re: Form Processing problem on pages with Border - Wicket 1.4.1
Flavius, I took the liberty: https://issues.apache.org/jira/browse/WICKET-2494 On Sat, Sep 26, 2009 at 12:24 AM, Flavius flav...@silverlion.com wrote: When I first posted this, I posted it multiple times thinking that it wasn't going through. Sorry about that. Pedro S had posted a reply to one of the duplicates I have since removed and I wanted to put it here: = The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. The objective is to notify form's event to generic containers... When the form is submitted, the DropDownChoice's value is being reset. you can implement the updateModel() of your DropDownChoice and implement the behavior you are expecting, or you can require on JIRA that the wicket form component stop notifying your components on generic containers. http://issues.apache.org/jira/browse/WICKET-1853 = I thought about this. Here's the problem: When I change the value I really do need to update the backing model. If I override updateModel (and don't call the super updateModel) my backing model will never be updated when the dropdown is changed. If I don't override it, or do and call the super method, I'll get a null value on every form submit from Form#component. I put a QuickStart up here: http://silverlion.com/flavius/BorderVisit.zip If you unzip it and run mvn jetty:run this will demonstrate what's going on. Just go to the home page and press the submit button. So overriding updateModel() isn't an option, as I see it. My choices that I see thus far are: 1. Alter the wicket source code to remove the updates on Border, which I really don't want to do because I haven't gone through everything to see what I will break doing that. 2. Move away from using a Border and lose the ability to swap out borders based on role/group, etc I would love a third option that I currently don't see. As a side note, I can see the benefit of notifying all the components in the border, but can't that be an optional thing? In my onSubmit() method, I can always call FormComponent.visitComponentsPostOrder(border, new FormModelUpdateVisitor(this)); But with the way it is now, I have no way to opt out of having my components updated. Is anybody else who uses borders having an issue like this? -- View this message in context: http://www.nabble.com/Form-Processing-problem-on-pages-with-Border---Wicket-1.4.1-tp25595716p25621988.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos
Re: Form Processing problem on pages with Border - Wicket 1.4.1
When I first posted this, I posted it multiple times thinking that it wasn't going through. Sorry about that. Pedro S had posted a reply to one of the duplicates I have since removed and I wanted to put it here: = The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. The objective is to notify form's event to generic containers... When the form is submitted, the DropDownChoice's value is being reset. you can implement the updateModel() of your DropDownChoice and implement the behavior you are expecting, or you can require on JIRA that the wicket form component stop notifying your components on generic containers. http://issues.apache.org/jira/browse/WICKET-1853 = I thought about this. Here's the problem: When I change the value I really do need to update the backing model. If I override updateModel (and don't call the super updateModel) my backing model will never be updated when the dropdown is changed. If I don't override it, or do and call the super method, I'll get a null value on every form submit from Form#component. I put a QuickStart up here: http://silverlion.com/flavius/BorderVisit.zip If you unzip it and run mvn jetty:run this will demonstrate what's going on. Just go to the home page and press the submit button. So overriding updateModel() isn't an option, as I see it. My choices that I see thus far are: 1. Alter the wicket source code to remove the updates on Border, which I really don't want to do because I haven't gone through everything to see what I will break doing that. 2. Move away from using a Border and lose the ability to swap out borders based on role/group, etc I would love a third option that I currently don't see. As a side note, I can see the benefit of notifying all the components in the border, but can't that be an optional thing? In my onSubmit() method, I can always call FormComponent.visitComponentsPostOrder(border, new FormModelUpdateVisitor(this)); But with the way it is now, I have no way to opt out of having my components updated. Is anybody else who uses borders having an issue like this? -- View this message in context: http://www.nabble.com/Form-Processing-problem-on-pages-with-Border---Wicket-1.4.1-tp25595716p25621988.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Form Processing problem on pages with Border - Wicket 1.4.1
I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Form Processing problem on pages with Border - Wicket 1.4.1
I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Form Processing problem on pages with Border - Wicket 1.4.1
I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form Processing problem on pages with Border - Wicket 1.4.1
The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. The objective is to notify form's event to generic containers... When the form is submitted, the DropDownChoice's value is being reset. you can implement the updateModel() of your DropDownChoice and implement the behavior you are expecting, or you can require on JIRA that the wicket form component stop notifying your components on generic containers. http://issues.apache.org/jira/browse/WICKET-1853 On Tue, Sep 22, 2009 at 10:46 AM, Flavius flav...@silverlion.com wrote: I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r%0Aelated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form Processing problem on pages with Border - Wicket 1.4.1
I mean override the updateModel :P On Tue, Sep 22, 2009 at 11:03 AM, Pedro Santos pedros...@gmail.com wrote: The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. The objective is to notify form's event to generic containers... When the form is submitted, the DropDownChoice's value is being reset. you can implement the updateModel() of your DropDownChoice and implement the behavior you are expecting, or you can require on JIRA that the wicket form component stop notifying your components on generic containers. http://issues.apache.org/jira/browse/WICKET-1853 On Tue, Sep 22, 2009 at 10:46 AM, Flavius flav...@silverlion.com wrote: I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r%0Aelated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Form Processing problem on pages with Border - Wicket 1.4.1
I am migrating a project from 1.3.6 to 1.4.1. I've run into a problem and I'm not sure if this is a bug or not. Most of the pages have a border and the border has a DropDownChoice in it (as well as other components). Technically it's in a panel in the border. The Form objects are typically children of the border, like add(border); border.add(inputForm); When the form is submitted, the DropDownChoice's value is being reset. I've traced through the code and it looks like the root of the cause is in Form#internalUpdateFormComponentModels. This is checking if there is a border and, if yes, then visiting all the components of the border. The internalUpdateFormComponentModels method in 1.3.6 didn't look for the border and visit it's components. It's not obvious to me why this needs to be done now in 1.4. So ultimately FormComponent#visitComponentsPostOrderHelper is being called for all components whether they are inside the form or not. It's returning visitor.component(component), which calls Form#component and that calls ((IFormModelUpdateListener)component).updateModel(); I looked through the nabble logs and noticed this entry here: http://www.nabble.com/Form-processing-issues-and-questions-%28particularly-r elated-to-Border-and-ListMultipleChoice%29-td25251849.html#a25251849 Is there something I need to do here? I'm not seeing any way of telling the Form not to visit the Border's controls, and again, I'm not sure why it's doing this. I'd greatly appreciate any insight that can be offered. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
