[
https://issues.apache.org/jira/browse/WICKET-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavius updated WICKET-2494:
----------------------------
Attachment: BorderVisit.zip
I've attached a QuickStart that demonstrates the issue here. This sample code
does "work" with wicket 1.3.x. It no longer "works" with 1.4.x. So, in the
strictest sense, the changes in 1.4.x eliminated backward compatibility. Now I
realize that with migration to a new major version, some refactoring is usually
necessary and I don't mind that at all. Even if it was a good amount of
refactoring that's fine.
But with this scenario, no amount of refactoring will allow the Border here
with a dropdown to work with the current codebase. To make this work, I've had
to go into the Form class and remove the call to
internalUpdateFormComponentModels for the Border component. This is not good,
but so far it seems to be working in this project without any adverse effects.
I haven't done a full regression test yet, though.
When I move to 1.4.2, and any subsequent 1.4.x build, I'll be forced to do the
same. Is there some way the 1.4.3 build can include an "opt out" for the
Border to not be visited on form submission? I realize this is no trivial
request, but I can't think of any other alternatives, other than altering the
Wicket
source code with each build or abandoning Borders altogether and losing all the
benefits gained from that.
If myBorder.getBorderBodyContainer().add(...) is the right way to do things
with a border, I would elect for that route. A javadoc comment can be added to
show users how this needs to be done and, as Igor mentioned, a warning message
to the dev otherwise can help them
> Outside form components problem
> -------------------------------
>
> Key: WICKET-2494
> URL: https://issues.apache.org/jira/browse/WICKET-2494
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket
> Affects Versions: 1.4.2
> Reporter: Pedro Santos
> Assignee: Juergen Donnerstag
> Attachments: BorderVisit.zip, patch.txt
>
>
> "It would be nice if any component can listen to form's event that signals
> form components to update their models"
> -There are some components that implemented they input logic using the
> request parameter (default FormComponet behavior). When Wicket bring those
> components outside the from to his processing, we get some problems: they
> will not receive the user input on page by request parameter map.
> Currently on the user mailing list we can see some case:
> http://markmail.org/search/list:org.apache.wicket.users#query:list%3Aorg.apache.wicket.users%20date%3A200909%20from%3A%22Flavius%22+page:1+mid:ykgrynnsyqaum22o+state:results
> If we execute the project sent ed by Flavius, we can see that the request has
> no parameter to the DropDownChoice component "project", that is on the page
> and outside the form. The component get his convertInput and updateModel
> called by the form process. The convertInput call getInputAsArray, that calls:
> String[] values = getRequest().getParameters(getInputName());
> and get null.
> To resolve that problem on wicket trunk, I'm sending a path that remove from
> the form processing, calls to components outside him(Flavius, maybe you want
> to apply on your workspace Wicket). But this is only an option. I think
> Wicket need review the way to process the form:
> 1- add inputs from outside form components to request
> 2 - remove outside form components from his processing
> 3 - any other option
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
