[
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 / ComponentFeedbackPanel that do not rely on
FeedbackMessage.getReporter. For example, the new ComponentFeedbackPanel could
use FeedbackCollector.
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.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> 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 / ComponentFeedbackPanel that do not rely on
> FeedbackMessage.getReporter. For example, the new ComponentFeedbackPanel
> could use FeedbackCollector.
>
--
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
