This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I've created a web application consisting of jsp, html, java beans, etc. What is supposed to happen is the user submits the web page, some java code kicks off that inserts records into a database table (there are various checks to see if the record has already been inserted for the customer number, and other checks). The problem I'm running into is that my code seems to be executing either out of order or randomly at various times, almost like it's running twice at the same time and stepping on itself. I'll have a record inserted into the database, then it will attempt to insert it again (generating an error). I can't figure out why it's doing what it's doing. It results in errors being sent back to the web page saying that the record was not inserted, when in fact it was. The error refers to the second attempt to insert it which shouldn't have occurred at all.
Now, I'm thinking maybe when the form is submitted, it somehow submits twice? (I have my submit button disable as soon as it's clicked and I'm sure I'm not somehow clicking twice every time). Or possibly when the page first loads my code is kicking off?
Here's some of my code (with redundant/unimportant bits cut out):
I know there are issues (java code in HTML etc, but can you see anything that would result in the code running multiple times, or twice at once. I'm really stuck on this one.
I'm obviously missing something. I read all the links and it makes sense, but actually getting it to work is not going so well. Right now, if I open my jsp, it is retaining and displaying the data entered previously. If I submit
my form, it is also still displaying all my data. What I really want it to do is retain the field values if there is
an error (so the user doesn't have to re-enter them), but if the process successfully updates my table, I want to
display a success message at the top of the screen, but remove all other field values. It doesn't seem like it
should be that hard but I've tried every combination of request.setAttribute, session.setAttribute, session.removeAttribute, both on the jsp page in this servlet and I either end up with all field values retained all
the time, or all values lost, including my error/success messages.
Any help or pointers in getting this to work is greatly appreciated.
Joined: Jun 04, 2007
I think a better choice would be to redirect the user to a seperate page in-case the validation succeeds.
but if the process successfully updates my table, I want to
display a success message at the top of the screen, but remove all other field values.
I think you can do something like
and in One.jsp:
Joined: Apr 11, 2008
I'm still having problems with it. It's still doing a double submit. I must be missing something. How can I prevent that double submit from happening?
The user clicks submit, it submits the form, and then I have to assume it's hitting my success page, redirecting back to my main page and submitting again when it reloads. When it reloads it still has all the fields filled in, even though I do a session.removeAttribute before doing the redirect.
I've tried setting the attributes for the request, and then I get no values any time, even when I want them to remain. And if I set the attributes for the session, then I always have values, even when I try to remove them. I'm so confused!
The code you're posting is *very* difficult to decipher: it's doing *way* to much in a single method. Even with the code elided it's still difficult to understand the code's intent because there are blocks of code that do nearly the exact same thing. If you simplify the code, group related functionality together, and so on, that will go a long way in helping you to understand what's actually happening.
Here's a trivial example where the cognitive/syntactic noise overwhelms the ability to think clearly:I have to read *every* line of *both* blocks to try to figure out the intent. Only then is it obvious that almost nothing is different, and it would be more clearly expressed as this:It also highlights a possible error in the original code; the "verifyFlag" request attribute is set regardless of the verifyFlag boolean value. Is that correct? I have no idea--it's hard to understand the code.
The original enrollCustomer() method is 200 lines long. By way of comparison, the *default* maximum method length in Checkstyle is 150. Lots of people get pretty twitchy when methods are longer than significantly less than that (myself included). Methods should strive to do one thing, and do it well. This makes them easier to understand (we spend more time *reading* code than writing it, and should optimize accordingly), easier to test, and so on.
Here's a trivial example of this concept applied to enrollCustomer():Right off the bat we see that the method is already doing too much, and things are in a confusing order. "Enrolling a customer" *depends* on "validating the form", but that doesn't mean that the entirety of "validating the form" belongs embedded in the enrollment itself--a prime candidate for refactoring. This also allows us to test the validation method in isolation.
One possible way to clarify this portion of the original method might be something like this (with the caveat that normally you'd just create an error message list and display it in a JSP rather than doing it by hand). It also highlighted a possible bug in the validation logic--if both values are null only one message would have been recorded.(Mind that there are probably syntax or copy/paste errors, but you get the idea.) The rules of whitespace apply to source code at least as much as the printed page, btw--and it's arguably even *more* important considering the nature of code comprehension.
Once the cognitive/syntactic noise is lessened it's far, *far* easier to understand what's happening, when, and why.
Joined: Apr 11, 2008
Thanks! That's exactly the type of feedback I need! I really want to do this stuff the right way, but there's a big learning curve. I'll work on cleaning this up and will keep plugging away at it. I have some reading (and re-reading) to do. Hopefully something will sink in soon.