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 >
