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
