[
https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467716#comment-13467716
]
Stefan Ocke edited comment on WICKET-4799 at 10/3/12 12:35 AM:
---------------------------------------------------------------
Mmh, I just looked at the diff in GIT:
https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have).
It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial
request. And now it shall be rendered again during an ajax request (but the
field shall not be validated again. I need to use the "old" message... ). But
the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields.
Adding new fields is the AJAX-Request. This request currently removes the
validation messages of already validates fields, since I have to AJAX-refresh
the whole list of fields when adding a new one. On the other hand, I cannot
re-create the messages by validating again, since adding new fields shall not
trigger (new) validation.
)
was (Author: stefanoc):
Mmh, I just looked at the diff in GIT:
https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least the one I have). It
does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial
request. And now it shall be rendered again during an ajax request (but the
field shall not be validated again. I need to use the "old" message... ). But
the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields.
Adding new fields is the AJAX-Request. This request currently removes the
validation messages of already validates fields, since I have to AJAX-refresh
the whole list of fields when adding a new one. On the other hand, I cannot
re-create the messages by validating again, since adding new fields shall not
trigger (new) validation.
)
> 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, 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
