Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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:
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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?
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Hi all,
IMHO Vladimir has made a reasonable suggestion.
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
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.
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Nothing broken on this side of the fence:
onclick(target) {
deleteRow();
if (target==null) {
// don't bother
} else {
target.addComponent(table);
}
}
Sven
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
In case of AjaxFallback components you would construct them anyway.
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
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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:
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
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
Proposal: Fake implementation of AjaxRequestTarget instead of null
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?
