Re: Request for Feature: NoopAjaxRequestTarget
On Sun, Aug 15, 2010 at 7:20 PM, Jeremy Thomerson 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" 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
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" 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
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" wrote: > > A. 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 > wrote: >> In the case of Aja... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
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" wrote: A. 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 wrote: > In the case of Aja...
Re: Request for Feature: NoopAjaxRequestTarget
A. 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 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
>> 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-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
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 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-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Request for Feature: NoopAjaxRequestTarget
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 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-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
