You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Hans Schäfer (JIRA)" <ji...@apache.org> on 2019/05/03 07:58:00 UTC

[jira] [Comment Edited] (WICKET-6663) Don't prevent requests on component placeholders (revert WICKET-6575)

    [ https://issues.apache.org/jira/browse/WICKET-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832318#comment-16832318 ] 

Hans Schäfer edited comment on WICKET-6663 at 5/3/19 7:57 AM:
--------------------------------------------------------------

Hi, 

a detailed description of the implementation that broke follows:

I have a component "search"-Panel that hast two sub-components: a search-field and a search-result-Panel. The search-field has an AjaxBehavior on "keyup" with throttling (800ms). So the Ajax-Processing of this AjaxBehaviour is triggered when the user stops entering the search term. In this case the search takes place and the search-result-Panel updates its search-results. If there are no search-results, the search-result-Panel is invisible.

Seems to be straight-forward to be implemented inside this one AjaxBehaviour, but there is a hard constraint: The backend that I have to use for searches is slow. Sometimes it takes several seconds until it answers. This lead to a blocking search-field in the straight-forward first implementation.

So I decoupled the steps that had to be done:
 # Update the search-term on the server-side
 # Do the search against the slow backend
 # Update the search-result.

I realized this by introducing additional elements: 
 # A IRequestMapper/IRequestHandler-Pair for processing the search: This pair is *not* processing a component-tree: it just receives the search-term, and calls a Spring-Service that does the search against the slow backend. The service caches the search result (using spring caching). 
 # A simple AjaxBehavior, that makes the Search-Result-Panel invisible, if there are no search results. It makes the Search-Result-Panel visible if there are search results. And it rerenders the Search-Result-Panel if onEvent is called.

The AjaxBehavior for event "keyup" on the search-field now does the following: Update the search-term on the server-side. Then return a Java-script that does the following: call the IRequestHandler (1) for processing the search term asynchronously. When this request returns successfully, fire the Ajax-Event on the AjaxBehavior (2), that rerenders the Search-Result-Panel. This rerendering ist fast, because the Search-Result-Panel gets the Search-Results form the cache (uses the same Spring-Service). 

Short summary: My visible sarch-field generates a script, that executes an Url for a component that is potentially invisible. 

 

Best regards

Hans 


was (Author: hosea):
Hi, 

a detailed description of the implementation that broke follows:

I have a component "search"-Panel that hast two sub-components: a search-field and a search-result-Panel. The search-field has an AjaxBehavior on "keyup" with throttling (800ms). So the Ajax-Processing of this AjaxBehaviour is triggered when the user stops entering the search term. In this case the search takes place and the search-result-Panel updates its search-results. If there are no search-results, the panel is invisible.

Seems to be straight-forward to be implemented inside this one AjaxBehaviour, but there is a hard constraint: The backend that I have to use for searches is slow. Sometimes it takes several seconds until it answers. This lead to a blocking search-field in the straight-forward first implementation.

So I decoupled the steps that had to be done:
 # Update the search-term on the server-side
 # Do the search against the slow backend
 # Update the search-result.

I realized this by introducing additional elements: 
 # A IRequestMapper/IRequestHandler-Pair for processing the search: This pair is *not* processing a component-tree: it just receives the search-term, and calls a Spring-Service that does the search against the slow backend. The service caches the search result (using spring caching). 
 # A simple AjaxBehavior, that makes the Search-Result-Panel invisible, if there are no search results. It makes the Search-Result-Panel visible if there are search results. And it rerenders the Search-Result-Panel if onEvent is called.

The AjaxBehavior for event "keyup" on the search-field now does the following: Update the search-term on the server-side. Then return a Java-script that does the following: call the IRequestHandler (1) for processing the search term asynchronously. When this request returns successfully, fire the Ajax-Event on the AjaxBehavior (2), that rerenders the Search-Result-Panel. This rerendering ist fast, because the Search-Result-Panel gets the Search-Results form the cache (uses the same Spring-Service). 

Short summary: My visible sarch-field generates a script, that executes an Url for a component that is potentially invisible. 

 

Best regards

Hans 

> Don't prevent requests on component placeholders (revert WICKET-6575)
> ---------------------------------------------------------------------
>
>                 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)