On Sat, Oct 24, 2009 at 5:23 PM, Vladimir K <koval...@gmail.com> wrote:
>
> Although it is possible I wouldn't recommend authoring certainly different UI
> basing on the asynchronisity of the request. For instance I experience
> inconvinience when mistakely opening Outlook Web Access in Firefox instead
> of MS IE and seeing a bit different non-ajaxy UI.
just because something is not to your "liking" doesnt mean it should
not be possible, so modify your proposal accordingly.
> From the other hand I would prefer to just call RequestTarget.isAjax() to
> distinguish what interface I should present to the user in case when it is
> reasonable different. Checking whether the object is null is much dangerous
> and non-self-descriptive. IMHO it is no-no design practice.
in that case it should just be an onclick() inside which you can do:
if (requestcycle.getrequesttarget() instanceof ajaxrequesttarget) {
....
}
-igor
>
> Since the number of fallback components is pretty small it is not difficult
> to derive from them some project-local components and wrap event handling in
> a manner I proposed to guard from NPE. But intention was to improve the
> Wicket API not only for that particular case.
>
>
> igor.vaynberg wrote:
>>
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Proposal%3A-Fake-implementation-of-AjaxRequestTarget-instead-of-null-tp26036327p26044281.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
