On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier <s...@meiers.net> wrote:
> I don't think he meant a *complete* no-op request target, just the method
> addComponent() would be a no-op. The fake request target will rerender the
> complete page as any other standard request would do.
this is not possible. all public contracts of the request target have
to be properly implemented. eg if a component was added it should be
returned by getcomponents(), also any registered listeners have to be
notified, etc.
i really dont understand the point of this change. if you have a fake
ajaxrequesttarget then the code for a fallback is essentially a noop,
so your app is broken in fallback.
most of the code i have written that utilizes the fallback
functionality looks like this:
onclick(target) {
if (target==null) {
setresponsepage(new editpage(...));
} else {
setupInp+laceEditPanel();
}
}
the workflows are divergent.
-igor
>
> BTW why don't we get rid of all those AjaxFallback... components and just
> let *all* Ajax... components support use of a standard HTML request as
> fallback?
>
> Regards
>
> Sven
>
> Martin Grigorov wrote:
>>
>> I think he meant wasting CPU cycles for constructing your components
>> which will be added to no-op ajaxrequesttarget
>>
>> then you'll have to make check like "if (target instanceOf
>> NullAjaxRequestTarget) {return;}" which is not better than before
>>
>> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
>>
>>>
>>> I think it absolutely makes sense (for a future release of wicket).
>>> having a NullObject instance of AjaxRequestTarget would not waste a lot
>>> of cpu cycles at all, at least not how i use it. the only thing i do with
>>> the object is call .addComponent() and then refering a already-initialized
>>> variable.
>>>
>>> how likely is it that the object is in fact null? its <5% of users who
>>> have javascript disabled. so this would affect only a small amount of
>>> requests.
>>>
>>> from a jvm perspective calling methods with empty bodys very often is not
>>> something expensive. they will get inlined by the hotspot compiler and be
>>> effectively free. (i am not 100% sure if this also applys to polymorphism
>>> chains.)
>>>
>>> from a "clean-code" prespective it is often considered a code smell to
>>> have a lot of null checks.
>>> in your example providing a FakeDatabaseConnection that throws an
>>> UnsrupportedOperationException("you have no database!") is better than
>>> seeing a null pointer exception.
>>>
>>>
>>>>
>>>> Sounds weird.
>>>>
>>>> Why should my component burn cpu cycles to feed a fake ajax target which
>>>> does nothing at all?
>>>>
>>>> I would prefer some null checks in that case.
>>>>
>>>> Would you also provide a FakeDatabaseConnection in case you application
>>>> does not support databases? :-)
>>>>
>>>>
>>>> Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
>>>>
>>>>
>>>>>
>>>>> I believe all those null-checks of request target can be omited in user
>>>>> code
>>>>> if fallback components would provide fake implementation of
>>>>> AjaxRequestTarget instead of passing null.
>>>>>
>>>>> Does it make sense?
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
