Agreed, I renamed the two methods for behaviors and the component itself.
Let's see how this works out. Regards Sven On 24.03.2016 08:20, Martin Grigorov wrote:
Hi Sven, I think it is a good idea to simplify this! I've made some minor comments on the commits. One thing that I don't like in the new code is #urlFor(new PageParameters()). It is not very clear what it will produce. Maybe we should rename that method to #urlForListener(PageParameters) ?! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Mar 23, 2016 at 2:58 PM, Sven Meier <[email protected]> wrote:Hi, I pushed a proposal to simplify requestListeners in Wicket 8.x to branch request_listener_simplification Let's take a look at a typical Wicket URL (an AjaxLink): http://examples7x.wicket.apache.org/ajax/links?1-1.IBehaviorListener.0-c1~link&_=1458735092123 It always bothered me why we're rendering "IBehaviorListener" into the URL. It lengthens the link and exposes an framework detail. Why is it done this way? Because Wicket needs it to identify the method to invoke on the receiving component or behavior. This is done via reflection, which complicates debugging into the receiving component - something I'm during regularly when I'm facing unknown applications/components. Additionally we have all those interfaces (e.g. IBehaviorListener) with INTERFACE constants which must be registered on the application: public static final RequestListenerInterface INTERFACE = new RequestListenerInterface(IBehaviorListener.class); What if Wicket just called a single method #onRequest() on any Component/Behavior that wants to receive requests: public interface IRequestListener extends IClusterable { /** * NEW Called when a request to is received. */ void onRequest(); } The URL above could be simplified to: http://examples7x.wicket.apache.org/ajax/links?1-1.0-c1~link&_=1458735092123 For those who are wondering about the numbers: - page instance 1 - page render count 1 - behavior id 0 There are two caveats to this simplification: - a component and/or behavior can no longer listen to two different types of requests (e.g. a Link that listens for clicks and for resource requests too) - I've never encounter such a component though AND you could always add an additional behavior if you really needed this, - RequestListenerInterface supported special handling of IResourceListeners, i.e. no render count in the URL and no scheduling of a RenderPageRequestHandler after invocation. I solved this by adding another method into IRequestListener: /** * Formerly RequestListenerInterface#includeRenderCount and #renderPageAfterInvocation */ boolean includeRenderCount(); Please take a look and report back your thoughts. Some tests are still failing, but I wanted to hear your opinion before rounding this up. Have fun Sven
