You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Don Ferguson <do...@gmail.com> on 2010/08/15 16:23:18 UTC
Request for Feature: NoopAjaxRequestTarget
When using AjaxRequestTarget, one always has to check for null, as in:
if (target != null) {
target.addComponent(...);
}
or suffer the consequences of an NPE at deployment time for users who don't have javascript enabled.
It would make life easier if Wicket just supplied a no-op AjaxRequestTarget into the onClick() method, rather than null. Then the code wouldn't need to check for null; the AjaxRequestTarget would always be instantiated. And if the code really needs to know whether it's dealing with an Ajax request, it can do an instanceof, as in:
if (! target instanceof NoopAjaxRequestTarget) {
....
}
Thoughts?
-Don
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Aug 15, 2010 at 7:20 PM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> It would break them, as == null would now return false where it previously
> was true.
>
Not exactly.
It will be true but it will be no-op, so the end behavior is the same.
This is possible even now. In our application we have a custom
AjaxRequestTarget that overrides addComponent(Component...) and does
nothing.
But we use it in our custom components, not in AjaxFallback** ones.
The other two add** methods in AJT are final so our class is a bit not
consistent, but we are aware of that.
>
> Jeremy Thomerson
> http://wickettraining.com
> -- sent from my "smart" phone, so please excuse spelling, formatting, or
> compiler errors
>
> On Aug 15, 2010 12:12 PM, "Don Ferguson" <do...@gmail.com> wrote:
>
> OK, filed as: https://issues.apache.org/jira/browse/WICKET-2991
>
> I am sensitive to the possibility of breaking existing code. I suppose the
> null check is most commonly used to determine whether or not to add
> components to the target, and this change would not break that use case,
> but
> no doubt there are other scenarios that I'm not considering.
>
>
> On Aug 15, 2010, at 9:29 AM, Jeremy Thomerson wrote:
>
> > File it as a JIRA. don't include there's pa...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-...
>
Re: Request for Feature: NoopAjaxRequestTarget
Posted by Jeremy Thomerson <je...@wickettraining.com>.
It would break them, as == null would now return false where it previously
was true.
Jeremy Thomerson
http://wickettraining.com
-- sent from my "smart" phone, so please excuse spelling, formatting, or
compiler errors
On Aug 15, 2010 12:12 PM, "Don Ferguson" <do...@gmail.com> wrote:
OK, filed as: https://issues.apache.org/jira/browse/WICKET-2991
I am sensitive to the possibility of breaking existing code. I suppose the
null check is most commonly used to determine whether or not to add
components to the target, and this change would not break that use case, but
no doubt there are other scenarios that I'm not considering.
On Aug 15, 2010, at 9:29 AM, Jeremy Thomerson wrote:
> File it as a JIRA. don't include there's pa...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-...
Re: Request for Feature: NoopAjaxRequestTarget
Posted by Don Ferguson <do...@gmail.com>.
OK, filed as: https://issues.apache.org/jira/browse/WICKET-2991
I am sensitive to the possibility of breaking existing code. I suppose the null check is most commonly used to determine whether or not to add components to the target, and this change would not break that use case, but no doubt there are other scenarios that I'm not considering.
On Aug 15, 2010, at 9:29 AM, Jeremy Thomerson wrote:
> File it as a JIRA. don't include there's part about instanceof checks;
> rather, a method should be added that returns a boolean.
>
> However, I'm not sure even then we could accept this since it would break so
> many existing applications' logic.
>
> Jeremy Thomerson
> http://wickettraining.com
> -- sent from my "smart" phone, so please excuse spelling, formatting, or
> compiler errors
>
> On Aug 15, 2010 10:51 AM, "James Carman" <ja...@carmanconsulting.com> wrote:
>
> Ahhhh. I've never encountered the fallback stuff, since my client's
> browsers always support JS. A null object would probably be better
> for this case. Good idea.
>
>
> On Sun, Aug 15, 2010 at 11:39 AM, Don Ferguson <do...@gmail.com>
> wrote:
>> In the case of Aja...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
Posted by Jeremy Thomerson <je...@wickettraining.com>.
File it as a JIRA. don't include there's part about instanceof checks;
rather, a method should be added that returns a boolean.
However, I'm not sure even then we could accept this since it would break so
many existing applications' logic.
Jeremy Thomerson
http://wickettraining.com
-- sent from my "smart" phone, so please excuse spelling, formatting, or
compiler errors
On Aug 15, 2010 10:51 AM, "James Carman" <ja...@carmanconsulting.com> wrote:
Ahhhh. I've never encountered the fallback stuff, since my client's
browsers always support JS. A null object would probably be better
for this case. Good idea.
On Sun, Aug 15, 2010 at 11:39 AM, Don Ferguson <do...@gmail.com>
wrote:
> In the case of Aja...
Re: Request for Feature: NoopAjaxRequestTarget
Posted by James Carman <ja...@carmanconsulting.com>.
Ahhhh. I've never encountered the fallback stuff, since my client's
browsers always support JS. A null object would probably be better
for this case. Good idea.
On Sun, Aug 15, 2010 at 11:39 AM, Don Ferguson <do...@gmail.com> wrote:
> In the case of AjaxFallbackLink (and maybe this is the only case where this really applies), the whole page is going to be re-rendered if javascript is not supported. So adding components to the target is superfluous.
>
> On Aug 15, 2010, at 7:44 AM, James Carman wrote:
>
>> How does the ajax logic get executed if the client doesn't have
>> Javascript enabled?
>>
>> On Sun, Aug 15, 2010 at 10:23 AM, Don Ferguson <do...@gmail.com> wrote:
>>> When using AjaxRequestTarget, one always has to check for null, as in:
>>>
>>> if (target != null) {
>>> target.addComponent(...);
>>> }
>>>
>>> or suffer the consequences of an NPE at deployment time for users who don't have javascript enabled.
>>>
>>> It would make life easier if Wicket just supplied a no-op AjaxRequestTarget into the onClick() method, rather than null. Then the code wouldn't need to check for null; the AjaxRequestTarget would always be instantiated. And if the code really needs to know whether it's dealing with an Ajax request, it can do an instanceof, as in:
>>>
>>> if (! target instanceof NoopAjaxRequestTarget) {
>>> ....
>>> }
>>>
>>> Thoughts?
>>>
>>> -Don
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
Posted by Don Ferguson <do...@gmail.com>.
In the case of AjaxFallbackLink (and maybe this is the only case where this really applies), the whole page is going to be re-rendered if javascript is not supported. So adding components to the target is superfluous.
On Aug 15, 2010, at 7:44 AM, James Carman wrote:
> How does the ajax logic get executed if the client doesn't have
> Javascript enabled?
>
> On Sun, Aug 15, 2010 at 10:23 AM, Don Ferguson <do...@gmail.com> wrote:
>> When using AjaxRequestTarget, one always has to check for null, as in:
>>
>> if (target != null) {
>> target.addComponent(...);
>> }
>>
>> or suffer the consequences of an NPE at deployment time for users who don't have javascript enabled.
>>
>> It would make life easier if Wicket just supplied a no-op AjaxRequestTarget into the onClick() method, rather than null. Then the code wouldn't need to check for null; the AjaxRequestTarget would always be instantiated. And if the code really needs to know whether it's dealing with an Ajax request, it can do an instanceof, as in:
>>
>> if (! target instanceof NoopAjaxRequestTarget) {
>> ....
>> }
>>
>> Thoughts?
>>
>> -Don
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
Posted by James Carman <ja...@carmanconsulting.com>.
How does the ajax logic get executed if the client doesn't have
Javascript enabled?
On Sun, Aug 15, 2010 at 10:23 AM, Don Ferguson <do...@gmail.com> wrote:
> When using AjaxRequestTarget, one always has to check for null, as in:
>
> if (target != null) {
> target.addComponent(...);
> }
>
> or suffer the consequences of an NPE at deployment time for users who don't have javascript enabled.
>
> It would make life easier if Wicket just supplied a no-op AjaxRequestTarget into the onClick() method, rather than null. Then the code wouldn't need to check for null; the AjaxRequestTarget would always be instantiated. And if the code really needs to know whether it's dealing with an Ajax request, it can do an instanceof, as in:
>
> if (! target instanceof NoopAjaxRequestTarget) {
> ....
> }
>
> Thoughts?
>
> -Don
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org