[
https://issues.apache.org/jira/browse/WICKET-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832296#comment-16832296
]
Hans Schäfer commented on WICKET-6663:
--------------------------------------
Hello all,
I try to explain detailed, why I think, that Wicket-6675 should be reverted.
The common challenge is, that you cannot make the browser sending requests in
strict order. The browser does not process the answer of a request before
sending the next request. The browser must not do that anyway, this is obvious:
the browser must parallelize requests.
Assume now, that a page is rendered and component A is visible. Now an
Ajax-Request R1 happens, immediately followed by an Ajax-Request R2 targeting
component A. Wicket now processes the requests in incoming order: The first
Request R1 changes state on the server-side. This state-change makes component
A invisible. Then Wicket processes Request R2, which targets now an invisible
component.
Summary: The state of a component that is reflected in the Markup in the
Browser and that is the basis for a request does not have to conform to the
state of the component when Wicket processes the request. So the changes of
Wicket-6675 do not solve this general problem: Its just Javascript-based
evaluation of the state of a component when the component was rendered. And the
Javascript makes the following wrong assumption: that a request to an invisible
component leads to an error. That is only true, if Method "canCallListener" is
not overridden.
My opinion is: wie must accept the fact, that Ajax-Requests can be fired and
the state has changed during the meantime until Wicket processes the request.
It is probably the best to make this fact more visible for programmers and give
them more hints in error messages.
My way of working with this is: If a component / behavior changes visibility
during Ajax-Requests it requires more of my attention. If it does not change
process-relevant state and just causes some kind or rerendering parts of the
HTML, I just override canCallListener with \{ return true; }. The
default-Implementation of canCallListener (throw Exception if component is
invisible or disabled), is to strict in this situation, it is OK if the
component just rerenders current state. There is no need to cause an error. I
also avoid owerwriting isVisible and I prefer setting visibility in
onConfigure, because it is more explicit.
Best regards
Hans
> WICKET-6575 - please revert
> ---------------------------
>
> Key: WICKET-6663
> URL: https://issues.apache.org/jira/browse/WICKET-6663
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 8.1.0
> Reporter: Hans Schäfer
> Priority: Major
>
> Hello!
> WICKET-6575 introduced a bug in my application.
> I explicitly make an Ajax-Call to an invisible component. In my case: this
> component displays search results as soon as they are available. The call is
> triggered by a script created by another (visible) component.
> The method "canCallListener" already models the behavior of
> components/behaviors regarding invocations. If you make Ajax-Calls to
> invisible components you can hook in here (the default-Implementation causes
> an exception if component is invisible) and make processing possible. This
> was a consistent server-side API until Wicket-6575.
> Please remove the changes of Wicket-6575.
> Thanks
> Hans
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
