I use similar approach and wondering.
... how to make sure that one year later another developer will realize that
there is a helper for her convinience?
svenmeier wrote:
>
> Hi,
>
> thinking more about this 'issue' I realized that in these simple cases
> one can just use a simple helper method:
>
> onclick(target) {
> AjaxHelper.addComponent(componentToReRenderOnAjaxRequest);
> }
>
> It was already discussed how components could automagically be added for
> re-rendering on each AjaxRequest.
> Such a feature would make a lot of calls to
> AjaxRequestTarget#addComponent() obsolete.
>
> Regards
>
> Sven
>
> Vladimir K 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.
>>
>> 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
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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-tp26036327p26046394.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
