Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java logic: form to database

 
mitchell bat
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys, i've got a question. I've created a form in java which tries to take the inputted information and then stores it in a MySQL database. At the moment what i've got is a login page that goes into the form page and when the submit button is selected the captured information gets sent to the database. I've got 2 main issues/questions, firstly i've got the button (action listener) handling the input to the database, is that the right thing to do? And secondly, when I log in the program skips the form page and goes to the frame after the form page. Could this have anything to do with the code inside my action listener or my JDBC connection class?

My connection class looks like this



and my actionListener in the form page looks like this

 
mitchell bat
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could the



code have something to do with it?
 
Campbell Ritchie
Sheriff
Posts: 51419
87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
mitchell bat wrote:Could the . . . code have something to do with it?
Don't know, but it looks wrong to dispose the frame when you have not finished with it. It also looks wrong to create a new instance at the end of the method.

Can you access the database without the GUI? I presume the answer is yes. Your business logic and the database access shoui‍ld be in different classes from the GUI. I presume you have already got that part working. I presume also that you have a (public?) interface to your business logic which can be used by the GUI. I don't like the design of that action performed method at all. You have all sorts of ifs and looks like procedural code and it looks difficult to maintain. What are you going to do if you open a branch at Adelaide? I would suggest you consider having a field which encapsulates the location and you can set that location with listeners on the location buttons. Similarly for the severities. I also think you shou‍ld move most of the connection and update code into a separate private method. Why are you calling setString(1, issueDBField)? Is that field suitable for use as a String to supply to a database update?

[edit]Question too difficult for “beginning”. Moving discussion, probably both to GUIs and databases.
 
mitchell bat
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Don't know, but it looks wrong to dispose the frame when you have not finished with it. It also looks wrong to create a new instance at the end of the method.


Because i'm still very new to programming that's how I have created my buttons when I need to go from one frame to another


Can you access the database without the GUI?


Yeah I can, I validated it


I presume also that you have a (public?) interface to your business logic which can be used by the GUI.


Your assumption is correct


What are you going to do if you open a branch at Adelaide?


For now this is just a muck around project to learn programming, when i'm done with this I plan on using the MVC approach which will allow allow for different things such as scalability just like how you mentioned about opening a branch in Adelaide.


Why are you calling setString(1, issueDBField)? Is that field suitable for use as a String to supply to a database update?


I think that the setString method taking the issueDBField string and storing it inside the database. Is that the wrong assumption?

 
Campbell Ritchie
Sheriff
Posts: 51419
87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
mitchell bat wrote:. . . that's how I have created my buttons when I need to go from one frame to another
You shou‍ld not use two frames. You should make dialogue windows visible if you need something to appear and disappear. As an alternative, you can use card layout to make the components you want visible come to the front, and later go to the back and disappear from view. Multiple frames sounds like a bad idea.
. . . I think that the setString method taking the issueDBField string and storing it inside the database. Is that the wrong assumption?
You shou‍ld never assume anything in programming. You shou‍ld ask somebody who knows the answer or look in the API documentation (or both). The setString method adds a String to the database update; if, later, the update is successfully executed, the String is added to the database. In that case, if issueDBField is a String, it is badly named. The name of a variable shou‍ld make it obvious what it means; that name obscures its meaning and confused me into thinking it was a field of some sort. Remember that Swing has about three classes called JSomethingField.
 
mitchell bat
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You shou‍ld not use two frames. You should make dialogue windows visible if you need something to appear and disappear. As an alternative, you can use card layout to make the components you want visible come to the front, and later go to the back and disappear from view. Multiple frames sounds like a bad idea.


Why is having 2 or more frames a bad idea?

Also, when it comes to storing the data in the database is the best way to do it by having the code in the action listener or is there a better way?


You shou‍ld never assume anything in programming. You shou‍ld ask somebody who knows the answer or look in the API documentation (or both). The setString method adds a String to the database update; if, later, the update is successfully executed, the String is added to the database. In that case, if issueDBField is a String, it is badly named. The name of a variable shou‍ld make it obvious what it means; that name obscures its meaning and confused me into thinking it was a field of some sort. Remember that Swing has about three classes called JSomethingField.


If you look at this code here



You can see that i've stored the input taken from the issueArea which is JTextArea as the String issueDBField.

What I don't understand is why it's not storing in the database. That's all I want it to do.
 
Knute Snortum
Bartender
Pie
Posts: 2903
62
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when it comes to storing the data in the database is the best way to do it by having the code in the action listener or is there a better way?

You need some code in the action listener, but most of it should be in a Data Access Object (Google java dao example).  For each table I have a model class and a DAO class that passes information back and forth from model (object) to DB.
 
mitchell bat
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reading that just blew my mind. I'll check it out, try it out and hopefully come back with questions
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic