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