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.
All the handlers of fallback components in my code perform the same logic
for ajax and non-ajax requests. The only difference is that I have to tell
Wicket what components are invalidated due to changes in data model. I find
it to be a good design style. That sort of information is just a garbage for
the current Wicket rendering algorithm but thing could be different in the
future if you decided to optimize the re-rendering process.
>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.
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
