SSH Framework Online Mall Project 19th War order information cascading warehousing and page caching issues _java

Shopping Cart This one has the last two questions left, is the order information cascaded warehousing and page caching, where the information refers to shopping carts and shopping items, that is, we will store the information of the cart in the database, but also in each shopping item information, and the foreign keys are related good, This involves the cascaded warehousing problem in the Hibernate; page caching problem refers to when the user confirmed the order, if the point back, will return to the order confirmation page, just the order confirmation page came out again, and the session is still, information or just information, this is obviously not the result we want, We'll analyze it in the back. This section focuses on cascading storage of order information and caching of pages.
1. Cascading storage of order information the cascading warehousing of the two relational tables in the
hibernate needs to be configured, here the main introduction of the annotation configuration, the order of the Pojo is Forder, shopping items Pojo is Sorder, Forder and Sorder are a one-to-many relationship, first we set their annotation configuration as follows:

@Entity public 
class Forder implements java.io.Serializable { 
  
 //Omitting extraneous code 
 
 ... Private list<sorder> sorders = new arraylist<sorder> (); 
 
 @OneToMany (cascade = cascadetype.all, fetch = fetchtype.lazy, Mappedby = "Forder") public 
 list<sorder> Getsorders () {return 
  this.sorders; 
 } 
 
 public void Setsorders (list<sorder> sorders) { 
  this.sorders = sorders; 
 } 
} 
 
@Entity public 
class Sorder implements java.io.Serializable { 
 
 //Omitting extraneous code 
 
 ... Private Forder Forder; 
 
 @ManyToOne (fetch = Fetchtype.lazy) 
 @JoinColumn (name = "FID") public 
 Forder Getforder () { 
  return This.forder; 
 } 
 
 public void Setforder (Forder forder) { 
  this.forder = Forder; 
 } 
} 

After this configuration, when we save the order item, we will also save the shopping item and automatically associate the foreign key. But the premise is that we want to set the relationship between them, that is, to Setsorders () in the Forder, to Setforder () in Sorder, and to the attributes in the entity corresponding to the other associated foreign key.
We've already implemented Forder.setsorder (Sorder) When we added shopping items to our shopping cart, and now we need to add Forder to the Sorder, so we added them to the original code, as follows:

This is the code in section 17, where we insert a sentence in the Middle @Service ("Sorderservice") public class Sorderserviceimpl extends baseserviceimpl<sorder> Implements Sorderservice {@Override public forder addsorder (Forder forder, product product) {Boolean Ishave = false; 
  Used to mark a repeat shopping item//Get the current shopping item Sorder Sorder = Producttosorder (product); Determines whether the current item is duplicated and, if it is repeated, adds a quantity for (Sorder old:forder.getSorders ()) {if (Old.getproduct (). GetId (). Equals (Sorder.getpro 
    Duct (). GetId ())) {//shopping item has duplicate, add quantity can Old.setnumber (Old.getnumber () + sorder.getnumber ()); 
    Ishave = true; 
   Break 
   }//The current item does not exist in the shopping cart, the new addition can be if (!ishave) {//We insert a clause here://Create a link to the shopping cart before adding a shopping item to the shopping, but at this point forder.id is null. 
   But in the warehousing time is the first warehousing shopping cart, then warehousing shopping items, then there will be a primary key sorder.setforder (Forder); 
  Forder.getsorders (). Add (Sorder); 
 return forder; 
  @Override Public Sorder Producttosorder (product product) {Sorder Sorder = new Sorder (); 
  Sorder.setname (Product.getname ()); Sorder.setnumber (1); 
  Sorder.setprice (Product.getprice ()); 
  Sorder.setproduct (product); 
 return sorder; 
 } 
}

OK, let's take a look at which action to jump to when the order is confirmed:

So we're going to complete the logic in Forderaction:

@Controller ("Forderaction") @Scope ("prototype") public class Forderaction extends baseaction<forder> {@Over 
  Ride public Forder Getmodel () {model = (Forder) session.get ("Forder"); 
 return model; //Implement the Shopping Cart (order) and the shopping item (order item) cascaded warehousing function Public String Save () {///////////////////Forder Forder = (Forder) 
Session.get ("Forder"); 
Model.setsorders (Forder.getsorders ()); 
Forder.setaddress (Model.getaddress ()); 
Forder.setname (Model.getname ()); 
Forder.setphone (Model.getphone ()); 
Forder.setremark (Model.getremark ()); 
Forder.setuser (user) Session.get ("User"); 
Forder.setstatus (New Status (1)); 
Forder.setpost (Model.getpost ()); 
Cascading warehousing (which needs to be configured in XML or Pojo annotations) requires Sorder Association Forder////Append Sorder.setforder (Forder) to the Sorderserviceimpl class; 
   
  Forderservice.save (Forder); 
  Model.setuser (user) Session.get ("User"); 
  Model.setstatus (New Status (1)); 
   
  Forderservice.save (model); 
 Return "bank"; 
 } 
}

As you can see from the above code, there are two methods: the first one that does not overwrite the Getmodel method (the part I commented out) is rather stupid, because the forderaction inherits the Baseaction, and the baseaction implements the Modeldriven interface, So the data will be encapsulated into model, model is a property in Baseaction, then we need to all the information in the model to the Forder in the session, and then the Forder data in order to be together with sorder cascaded warehousing, But this method is a bit stupid ... So we use the second method, rewrite the Getmodel method, directly to the Forder to model can, and then we just add the model of the item can be added, that is, the above-annotated code. So the user clicks on the order confirmation, information warehousing, jump to the Payment page (Pay page next to do, now casually jump to a JSP can).

2. Page Caching problem
now the order information cascaded warehousing solution, but if the user clicks confirm the order, then back, we found that the original order confirmation page, and the information is just the information, the session is not closed, that is, the equivalent of me to confirm the order information, which is obviously improper, that is to say, When the user clicks on the confirmation order, we cannot let the page cache, so that when the user clicks back, it will show that the page has expired, we let it jump to the homepage.
We know that in the foreground JSP page can be set so that the browser does not cache the data, so we can set the following confirm.jsp page in the foreground:

But the problem is not so simple, this is not the case, the user clicks back is the page has expired prompts, but when the user is not refreshed, it will show the cache load the original data. So we understand a little, because the session has not closed, the session has orders of information Forder, users refresh will certainly continue to get this forder, will display the original order information, so only in front of this setting can not solve the problem, We also need to do related processing in the backstage.
Now that we know what the problem is, we can do this: because when the user clicks on the confirmation order, he gives it to forderaction, and then forderaction to the payment page after processing. We can do some hands and feet in the forderaction: we will be in the session of the original Forder to clear off, that is not OK? This is possible, but given the need for order information to be paid later, we can save the original Forder in the session to another place and then empty the original Forder, so we add two lines of code to the forderaction above. is as follows:

@Controller ("Forderaction") @Scope ("prototype") public class Forderaction extends baseaction<forder> {@Over 
  Ride public Forder Getmodel () {model = (Forder) session.get ("Forder"); 
 return model; //Implement the Shopping Cart (order) and the shopping item (order item) cascaded warehousing function Public String Save () {///////////////////Forder Forder = (Forder) 
Session.get ("Forder"); 
Model.setsorders (Forder.getsorders ()); 
Forder.setaddress (Model.getaddress ()); 
Forder.setname (Model.getname ()); 
Forder.setphone (Model.getphone ()); 
Forder.setremark (Model.getremark ()); 
Forder.setuser (user) Session.get ("User"); 
Forder.setstatus (New Status (1)); 
Forder.setpost (Model.getpost ()); 
Cascading warehousing (which needs to be configured in XML or Pojo annotations) requires Sorder Association Forder////Append Sorder.setforder (Forder) to the Sorderserviceimpl class; 
   
  Forderservice.save (Forder); 
  Model.setuser (user) Session.get ("User"); 
  Model.setstatus (New Status (1)); 
   
  Forderservice.save (model); At this point the shopping cart has been in storage, then the original session of the shopping cart should be emptied session.Put ("Oldforder", Session.get ("Forder")), and/or first save the original shopping cart information, because the following payment will also need relevant information session.put ("Forder", New Forder ()); 
 New empty shopping cart (equivalent to empty the shopping cart), but also convenient for users to buy ~ return "bank"; 
 } 
}

And then it's not over, we'll confirm the order page at the front desk and add the following code:

Now the logic is clear, first to the order confirmation page, Forder is the data, so not empty, this judgment is invalid, when the user clicks Confirm order, in Forderaction we will forder replaced by an empty Forder object, That means the original data is gone (we save it in a second key value pair in the session, for the back to pay to use, so when the user point back and back to just the order confirmation page, the judgment will be effective, will jump to the home page, here, the entire logic is complete, the page caching problem solved.
Original address: http://blog.csdn.net/eson_15/article/details/51433247

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.