You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Sven Meier <sv...@meiers.net> on 2016/03/23 14:58:52 UTC
simplify request listeners in 8.x
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
Re: simplify request listeners in 8.x
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@meiers.net> 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
>>
Re: simplify request listeners in 8.x
Posted by Martin Grigorov <mg...@apache.org>.
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 <sv...@meiers.net> 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
>