it may very well be, but it is not a framework's job to dictate
business requirements.
-igor
On Sun, Oct 25, 2009 at 2:01 AM, Vladimir K <koval...@gmail.com> wrote:
>
> Consistent UI is very important for the user, isn't it? It has nothing in
> common with my "liking".
>
> My proposal is about how to make the Wicket user life simpler. Not only by
> omitting coding null-checks. It is about bugs related to forgotten
> null-checks. And it is about consistent API.
>
> I strive to limit the places where use of instanceof operator is by-design.
>
>
> igor.vaynberg wrote:
>>
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Proposal%3A-Fake-implementation-of-AjaxRequestTarget-instead-of-null-tp26036327p26046187.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
