You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Stefan Ocke (JIRA)" <ji...@apache.org> on 2012/10/02 20:01:08 UTC
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira