• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Clear bean values onLoad

 
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not really sure if I should put this in the JSP forum or the Servlet forum. I'm sure if it should be moved someone will take care of that ;)

I have a search jsp. It submits a form and my servlet picks up the values and builds an SQL statement. I pass the SQL statement from my servlet out to some classes that make a bean which holds the values I need for that particular order. I check to see if there is a cancel date on the order and if there is I send them to an error page, tell them they entered a bad order number, and redirect back to my original search jsp.

If I reenter the same order number and resubmit the form it does not catch that the bean value is '0'. It just redirects on to the page I use to display results. My question is how do I get of the old bean instance before I run this again. Should I do it onLoad in my <body> tag or do it in my servlet's doPost method before I start executing?

I've searched around for a solution to this but haven't found anything that is overly helpful yet...
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Where are you storing the bean? If it's in request scope, it's long gone by the time any new request is made.

Sounds like you want to store it in the session so you can retrieve and inspect it at a later time.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
P.S. Building SQL statements in a servlet? Wouldn't it be better to sequester all your back-end code in a UI-agnostic layer a la MVC?
 
Bryce Martin
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basic Structure I'm working with...


Selection.jsp (5 fields, 8 valid selection combinations)---calls FormManager servlet-->>
FormManager.java which extends servlet (responsible for forwarding response to proper jsp based on which of 8 combinations was used) ---build the specific sql I need for that combination, then passes the sql to a java class that does all my result set processing(calls connection class, and logic classes).

I am returned a bean. I then do a request.setAttribute and put the bean into the request. Then, I see if the cancel date in the bean != 0. If it does it goes to the error.jsp, if not it goes on to the regular order page. Now, I do create a bean in the doPost that holds the returned bean. And that is what I'm setting in the request.

The next time it runs, even though the value being returned will still be !=0 from the db, but it forwards on to the regular page instead of hitting the error page...and I don't know why...
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I repeat: scoped variables (beans or otherwise) placed on the request go out of scope when the request terminates and the response is sent to the browser. Expecting it to still be there (where's there? the request has long since been dismissed!) on a subsequent request only leads to heart-ache.

If you want a scoped variable to have a lifetime beyond a single request, session scope is the place.

With regards to your app structure, have you ever read this article?
[ December 20, 2007: Message edited by: Bear Bibeault ]
 
Bryce Martin
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So let me try to make this easy, you should be able to look at this code and quickly tell me what I need to move out into classes to make this true MVC. I know that I'm pretty close, I just need a little bump to get me all the way in I think...



I'm going to create a class and make methods in that class for my sql statements. I know I need to get that out. But what about any of the other stuff?

[ December 21, 2007: Message edited by: Bryce Martin ]
[ December 21, 2007: Message edited by: Bryce Martin ]
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bryce Martin:
look at this code and quickly tell me what I need to move out into classes to make this true MVC.



A better idea: remove the imports for the sql and io classes and see what breaks. That's what's got to go.

The higher-level principle is to imagine that you are putting a non-Web interface on your model. Would you place the SQL generation in a servlet if you were putting a Swing UI on the model?
 
Bryce Martin
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good point Bear. Thanks a ton. I'll remove those and clean it up. I'm really trying to embrace this stuff and get it working properly so that when I do some major development down the road I'll be doing it all right.

Thanks again.
Bryce
 
Bryce Martin
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I take out the io stuff, then I have to do the forward responses somewhere else right? Where do I do them? Call some other class to do it? Do I lose my request scope doing that?
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Including IOException is fine. Just don't be doing any IO that the model should be doing.

P.S. PLEASE fix your posted code so that this topic isn't 5 miles wide.
 
Bryce Martin
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm only doing the requestDispatcher from the servlet. If I'm correct, this is what a servlet is for anyway to direct the traffic. And I'm directing the traffic based on the form input.

Should I be doing this stuff in the doGet method instead of doPost? Is that going to matter? Is that what I should be doing to conform to PRG? I'm moveing out that pesky sql. I have to write a couple more classes to write yet. Once I'm done it will be basically like this...

[ December 21, 2007: Message edited by: Bryce Martin ]
 
Are we home yet? Wait, did we forget the tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic