Reset form on error
Hi all,
I have one page to add and edit shopping items. Certain fields are
required. The fields are bound to the request bean. If I edit
an item and leave a required field empty, I get the error message
as expected. When I now leave the page and press add new item,
I get the item back I previously edited with the empty field and the red marker.
I would expect to have empty fields again, because the Request
has finished and a new one starts. The request bean seems to
be "cached" if there are errors on the page. I guess this is a kind
of feature. But, is it possible to reset the form, so I can add new
items?
If there are no errors on the page, the application works fine, I can
switch between my items and add new ones. But on the first error, I get
stuck. The error is sticky. If I resolve the error, then I can go on.
So, is there a way to reset the form/validators/error handlers - I don't
know which one is responsible for this.
Thanks for any help, Heike
[1069 byte] By [
hfra] at [2007-11-26 9:28:46]
# 1
> If I edit an item and leave a required field empty, I get the
> error message as expected.
> When I now leave the page and press add
> new item, I get the item back I previously edited with the
> empty field and the red marker.
How do you leave the page? I thought with required fields not filled out any navigation is cancelled and you just get the same page again and again?
I think there could be the key to your problem.
Use the debugger (F5) and the HTTP Monitor to have a look at your requests you are sending. It might be the Browser is resending the same post data again when resubmitting.
Hope that helps,
Juergen
# 2
Hi Juergen,
thanks for your reply ;-)
> How do you leave the page? I thought with required
> fields not filled out any navigation is cancelled and
> you just get the same page again and again?
Well, I have a navigation bar. And clicking any link I can get
on any page of my application I want to. So, navigation is not
cancelled.
> I think there could be the key to your problem.
>
> Use the debugger (F5) and the HTTP Monitor to have a
> look at your requests you are sending. It might be
> the Browser is resending the same post data again
> when resubmitting.
I did some debugging already and now also used an http monitor.
The result is: the browser sends the request for the page
and the server returns the page with the red marker, and an
http: 304 Not Modified. I can see that the prerender
method is called and my hidden fields - not bound to the request
bean - are set as expected. The attributes in the request bean
are "null" during "prerender". So, the values are set somewhere afterwards.
Well, now I know definitely that it's no browser issue.
I am hoping for further help. This problem worries me a bit. I can't tell
my user to log off and relogon when he does not want to resolve an
error in his inputs.
Thanks, Heike
hfra at 2007-7-7 0:10:50 >
# 3
Hello Heike,
> > How do you leave the page? I thought with required
> > fields not filled out any navigation is cancelled
> > and you just get the same page again and again?
> Well, I have a navigation bar.
Which is no reason to get anywhere. :)
> And clicking any link I can get
> on any page of my application I want to. So,
> navigation is not cancelled.
The standard navigation algorithm of JSF takes three inputs:
* The outcome (the value of an action attribute or the string resulting from invocation of a method reference)
* The view ID of the current view
* The action (the literal value of the action attribute in the component that triggered the navigation)
The page to see next is derived from this input and the navigation rules set in faces-config.xml
If a field in a form is required and not set the navigation algorithm will direct you to the same page again with the error messages.
Of course you can circumvent the navigation algorithm of JSF and use "hardcoded" HTML Links in your page.
If you do this and return to the page the server/session might not "realize" that you ever left the page and just take this as a "reload" request.
> I did some debugging already and now also used an
> http monitor.
I meant the http Monitor of JSC2 which also gives you detailed information about the state of the session and the context. This information might help you.
You have to switch on the http Monitor in the "deployment Server" -> "properties" and you have to start the server in debug mode.
> The result is: the browser sends the request for the
> page
> and the server returns the page with the red marker,
> and an
> http: 304 Not Modified. I can see that the prerender
> method is called and my hidden fields - not bound to
> the request
> bean - are set as expected. The attributes in the
> request bean
> are "null" during "prerender". So, the values are set
> somewhere afterwards.
304 Not modified - normally means that the page is not transmitted but served from the browsers cache.
You could make the experiment and clean the cache of the browser after leaving the page.
> Well, now I know definitely that it's no browser
> issue.
I am not convinced.
> I am hoping for further help. This problem worries me
> a bit. I can't tell
> my user to log off and relogon when he does not want
> to resolve an error in his inputs.
You are right.
Hope you get to the solution soon,
Juergen
# 4
Hello Juergen,
thanks again for your detailed reply.
> Which is no reason to get anywhere. :)
Right ;-)
> Of course you can circumvent the navigation algorithm
> of JSF and use "hardcoded" HTML Links in your page.
No, of course I don't like this.
OK, I did some further debugging, with the right http
monitor (this one is really better ;-)
> 304 Not modified - normally means that the page is
> not transmitted but served from the browsers cache.
> You could make the experiment and clean the cache of
> the browser after leaving the page.
The page is reloaded. The "not modified" belonged to an image (my
error, I misinterpreted the http status code).
I can for example set a different headline and my hidden attributes
are different. So, it really is a different page - so no browser cache.
And: the error message is gone, too. So, there are only the input
fields that course the trouble.
In the http monitor I could see that the whole page xxx.jsp is stored in the
session. Is this a normal behaviour, or have I implemented something to
force this - I cannot find a hint in my code ?
This all brings me back to my question at the beginning: can I reset
the error handler? Or should I remove the xxx.jsp from the session
manually? Or .... ?
I am sure there is a way to let creator forget the errors.
Thanks for any further help in advance, Heike
hfra at 2007-7-7 0:10:50 >
# 5
Heike,
Have you tried your application on a standalone copy of the application server? I've seen this behavior many times on the Creator bundled version of the application server. However, the same applications then would work perfectly when running on a standalone server. I抳e given up on trying to figure out why it does this?I guess a bug in the creator version of application server.
Hope this helps.
jsr at 2007-7-7 0:10:50 >
# 6
Hi,
thanks for your reply. But in tomcat it's the same behaviour.
So, it's something deep down in creators generated code.
> Have you tried your application on a standalone copy
> of the application server? I've seen this behavior
> many times on the Creator bundled version of the
> application server. However, the same applications
> then would work perfectly when running on a
> standalone server. I抳e given up on trying to figure
> out why it does this?I guess a bug in the creator
> version of application server.
>
I am thankful for any further help, Heike
hfra at 2007-7-7 0:10:50 >
# 7
> as expected. When I now leave the page and press add
> new item,
> I get the item back I previously edited with the
> empty field and the red marker.
> I would expect to have empty fields again, because
> the Request
> has finished and a new one starts. The request bean
> seems to
> be "cached" if there are errors on the page. I guess
> this is a kind
> of feature.
I thought about this again. There is one case mentioned in "Core Java Server Faces" when the request scope is extended:
"If a request is forwarded to another request, all name/value pairs stored in the request scope are carried over to the new request. On the other hand, if a request is redirected, the request data are lost."
I do not see wether or not this might be important for the solution of your problem, but for me it is the only known extension of the request scope.
One last go:
Of course you did already spread breakpoints all over your request bean and start the application with the debugger to see the values read out the time you return to the page?
Juergen
# 8
Did you find a solution?
# 9
This tutorial might help you understand request scope:
http://developers.sun.com/prodtech/javatools/jscreator/learning/tutorials/2/sco pes.html
For example, it says Request scope begins when the user submits the page and ends when the response is fully rendered, whatever page that is.
Have you tried the erase() method as described in http://developers.sun.com/prodtech/javatools/jscreator/reference/docs/apis/appb ase/com/sun/rave/web/ui/appbase/FacesBean.html? Not sure this will work but it just might.
An indepth description of the application model can be found at http://developers.sun.com/prodtech/javatools/jscreator/reference/techart/2/app_ model.html
# 10
Hi all,
after some time now, I am coming back to this. I still have not found
a solution.
Thanks for the tip, but Erase() won't help .. sorry to say.
For testing I have created a new project, and it is still the same.
I give you the details, so you can easily reproduce it:
Page1.jsp
hyperlink named add url set to: /faces/newPage.jsp
hyperlink named edit url set to: /faces/newPage.jsp?action=edit
newPage.jsp
inputField with lengthValidator set to 5
hyperlink submit
with the following code:
public String hyperlink1_action() {
getSessionBean1().setInput((String)getTextField1().getText());
return "back";
}
public void prerender() {
String action = (String)getExternalContext().getRequestParameterMap().get("action");
if(action != null && action.equals("edit")){
getRequestBean1().setInput(getSessionBean1().getInput());
}
}
storing the value of the input field in session bean.
In Page Navigation "back" is linked back to Page1.
So, now try using "add" and "edit" with string length <5 and string length > 5
and you get the results as described above.
If any one is interested, I can email the project.
I am really thankful for a solution of this issue.
Heike
hfra at 2007-7-7 0:10:50 >
# 11
Hi all,
after all coming back to this.
And in the end, I have found a working solution.
On edit/add I have to call erase() and iterate over all TextFields and call
setValid(true) manually.
It is not really nice, but at least it works ;-))
I hope that the creator team will find a better solution. As I am still
convinced that every application must have this problem, when
it provides editing fields and using validators.
Thanks for all your help,
Heike
hfra at 2007-7-7 0:10:50 >
