Difference between returning null and “” from a JSF action The Next CEO of Stack OverflowJSF Navigation String, Null, Context Redirect & the method continuesJSF bean action method return string testupdate a bean property from the same jsfa4j jsFunction not triggering server side methodWhy does returning empty string from action method not recreate view?Problems navigating in a JSF Single Page Applicationp:commandButton not updating panelEditing a single row of mysql using JSFh:commandButton with an action and then page-navigation in JSF?Differences between HashMap and Hashtable?What is the difference between public, protected, package-private and private in Java?Difference between StringBuilder and StringBufferDifference between wait() and sleep()What is the difference between JSF, Servlet and JSP?Difference between HashMap, LinkedHashMap and TreeMapDifferences between action and actionListenerWhat's the difference between @Component, @Repository & @Service annotations in Spring?Making Distinctions Between Different Kinds of JSF Managed-BeansJSF bean action method return string test
Reference request: Grassmannian and Plucker coordinates in type B, C, D
Running a General Election and the European Elections together
Proper way to express "He disappeared them"
WOW air has ceased operation, can I get my tickets refunded?
How to invert MapIndexed on a ragged structure? How to construct a tree from rules?
Why this way of making earth uninhabitable in Interstellar?
Would a completely good Muggle be able to use a wand?
What connection does MS Office have to Netscape Navigator?
Is it okay to majorly distort historical facts while writing a fiction story?
How did people program for Consoles with multiple CPUs?
Is it possible to replace duplicates of a character with one character using tr
What happened in Rome, when the western empire "fell"?
Help understanding this unsettling image of Titan, Epimetheus, and Saturn's rings?
Is it professional to write unrelated content in an almost-empty email?
Unclear about dynamic binding
Math-accent symbol over parentheses enclosing accented symbol (amsmath)
How to scale a tikZ image which is within a figure environment
Does Germany produce more waste than the US?
Some questions about different axiomatic systems for neighbourhoods
No sign flipping while figuring out the emf of voltaic cell?
What did we know about the Kessel run before the prequels?
Solving system of ODEs with extra parameter
Would a grinding machine be a simple and workable propulsion system for an interplanetary spacecraft?
Example of a Mathematician/Physicist whose Other Publications during their PhD eclipsed their PhD Thesis
Difference between returning null and “” from a JSF action
The Next CEO of Stack OverflowJSF Navigation String, Null, Context Redirect & the method continuesJSF bean action method return string testupdate a bean property from the same jsfa4j jsFunction not triggering server side methodWhy does returning empty string from action method not recreate view?Problems navigating in a JSF Single Page Applicationp:commandButton not updating panelEditing a single row of mysql using JSFh:commandButton with an action and then page-navigation in JSF?Differences between HashMap and Hashtable?What is the difference between public, protected, package-private and private in Java?Difference between StringBuilder and StringBufferDifference between wait() and sleep()What is the difference between JSF, Servlet and JSP?Difference between HashMap, LinkedHashMap and TreeMapDifferences between action and actionListenerWhat's the difference between @Component, @Repository & @Service annotations in Spring?Making Distinctions Between Different Kinds of JSF Managed-BeansJSF bean action method return string test
From what I understand, when a JSF action returns "" (empty String) the user stays on the current page but the view is refreshed. However, when the action returns null the user still stays on the current page but the old view is reused. My question is:
- Is the above statement correct (accurate)?
- If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
- In what situations should one be used over the other?
java jsf navigation
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
add a comment |
From what I understand, when a JSF action returns "" (empty String) the user stays on the current page but the view is refreshed. However, when the action returns null the user still stays on the current page but the old view is reused. My question is:
- Is the above statement correct (accurate)?
- If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
- In what situations should one be used over the other?
java jsf navigation
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
add a comment |
From what I understand, when a JSF action returns "" (empty String) the user stays on the current page but the view is refreshed. However, when the action returns null the user still stays on the current page but the old view is reused. My question is:
- Is the above statement correct (accurate)?
- If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
- In what situations should one be used over the other?
java jsf navigation
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
From what I understand, when a JSF action returns "" (empty String) the user stays on the current page but the view is refreshed. However, when the action returns null the user still stays on the current page but the old view is reused. My question is:
- Is the above statement correct (accurate)?
- If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
- In what situations should one be used over the other?
java jsf navigation
java jsf navigation
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
edited Jan 5 '12 at 14:47
Perception
68.9k10150174
68.9k10150174
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
asked Jan 5 '12 at 14:31
Brent CBrent C
5251713
5251713
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Is the above statement correct (accurate)?
Yes. Instead of returning null you can also just return void.
If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
Nothing on request scoped beans. It has only effect on JSF2 view scoped beans. On returning null or void, the view scoped bean instance will be retained in the next request, else it will be recreated.
In what situations should one be used over the other?
If you want to retain the JSF2 view scoped bean in the subsequent request.
See also:
- Communication in JSF 2.0 - Managed bean scopes
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always returnnullorvoidon postbacks to the same view.
– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use avoidreturn type, but can't remember which vendor/version.
– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by aMethodExpressionis a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.
– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f8744162%2fdifference-between-returning-null-and-from-a-jsf-action%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is the above statement correct (accurate)?
Yes. Instead of returning null you can also just return void.
If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
Nothing on request scoped beans. It has only effect on JSF2 view scoped beans. On returning null or void, the view scoped bean instance will be retained in the next request, else it will be recreated.
In what situations should one be used over the other?
If you want to retain the JSF2 view scoped bean in the subsequent request.
See also:
- Communication in JSF 2.0 - Managed bean scopes
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always returnnullorvoidon postbacks to the same view.
– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use avoidreturn type, but can't remember which vendor/version.
– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by aMethodExpressionis a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.
– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
|
show 1 more comment
Is the above statement correct (accurate)?
Yes. Instead of returning null you can also just return void.
If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
Nothing on request scoped beans. It has only effect on JSF2 view scoped beans. On returning null or void, the view scoped bean instance will be retained in the next request, else it will be recreated.
In what situations should one be used over the other?
If you want to retain the JSF2 view scoped bean in the subsequent request.
See also:
- Communication in JSF 2.0 - Managed bean scopes
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always returnnullorvoidon postbacks to the same view.
– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use avoidreturn type, but can't remember which vendor/version.
– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by aMethodExpressionis a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.
– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
|
show 1 more comment
Is the above statement correct (accurate)?
Yes. Instead of returning null you can also just return void.
If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
Nothing on request scoped beans. It has only effect on JSF2 view scoped beans. On returning null or void, the view scoped bean instance will be retained in the next request, else it will be recreated.
In what situations should one be used over the other?
If you want to retain the JSF2 view scoped bean in the subsequent request.
See also:
- Communication in JSF 2.0 - Managed bean scopes
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
Is the above statement correct (accurate)?
Yes. Instead of returning null you can also just return void.
If yes, then what are the implications of this? Specifically, what effect does using one versus the other have on data on the page (values in JSF UI components, or data stored in a request-scope bean in a DataTable, for example)?
Nothing on request scoped beans. It has only effect on JSF2 view scoped beans. On returning null or void, the view scoped bean instance will be retained in the next request, else it will be recreated.
In what situations should one be used over the other?
If you want to retain the JSF2 view scoped bean in the subsequent request.
See also:
- Communication in JSF 2.0 - Managed bean scopes
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
answered Jan 5 '12 at 14:33
BalusCBalusC
857k30031743237
857k30031743237
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always returnnullorvoidon postbacks to the same view.
– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use avoidreturn type, but can't remember which vendor/version.
– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by aMethodExpressionis a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.
– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
|
show 1 more comment
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always returnnullorvoidon postbacks to the same view.
– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use avoidreturn type, but can't remember which vendor/version.
– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by aMethodExpressionis a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.
– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
So if I am using JSF 1.2 without a view-scope, then it is safe to say there is really no difference?
– Brent C
Jan 5 '12 at 14:42
1
1
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always return
null or void on postbacks to the same view.– BalusC
Jan 5 '12 at 14:49
Functionally, no. But technically there's a difference which you already found out yourself. Creating a new view has a minor cost. Just always return
null or void on postbacks to the same view.– BalusC
Jan 5 '12 at 14:49
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use a
void return type, but can't remember which vendor/version.– McDowell
Jan 5 '12 at 16:13
FYI: Application Actions have the following constraints in the JSF2 spec: 1. The method must be public. 2. The method must take no parameters. 3. The method must return Object. I recall at least one navigation API implementation blowing up if you tried to use a
void return type, but can't remember which vendor/version.– McDowell
Jan 5 '12 at 16:13
@McDowell: in reality, anything which can be represented by a
MethodExpression is a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.– BalusC
Jan 5 '12 at 16:27
@McDowell: in reality, anything which can be represented by a
MethodExpression is a legal action method, even the ones taking parameters as possible in EL 2.2. That spec cite is perhaps a leftover from JSF 1.0.– BalusC
Jan 5 '12 at 16:27
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
Is this difference in treating of response value covered in spec or it is just implementation thing?
– Tibor Blenessy
Sep 30 '14 at 11:38
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f8744162%2fdifference-between-returning-null-and-from-a-jsf-action%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
