There are two remaining problems in the shopping cart, namely the cascaded storage of order information and page cache. The information here refers to the shopping cart and shopping items. That is, when we store the information of the shopping cart into the database, we also store the information of each shopping item, and the foreign keys are related, which involves the cascaded storage issue in Hibernate; the page cache problem refers to the time when the user confirms the order, if he clicks back, he will return to the order confirmation page. The order confirmation page just now comes out again, and the session is still there, and the information is still the information just now. This is obviously not the result we want, and we will analyze it one by one later. This section mainly discusses the cascading inventories of order information and the caching of pages.
1. Cascading storage of order information
The cascading storage of two related tables in Hibernate needs to be configured. Here we mainly introduce the configuration method of annotations. The POJO of the order is Forder, the POJO of the shopping item is Sorder, and the Forder and Sorder are one-to-many relationships. First, let’s set their annotation configuration, as follows:
@Entity public class Forder implements java.io.Serializable { //Omit irrelevant code... private List<Sorder> soorders = new ArrayList<Sorder>(); @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "forder") public List<Sorder> getSorders() { return this.sorders; } public void setSorders(List<Sorder> soorders) { this.sorders = soorders; } } @Entity public class Sorder implements java.io.Serializable { //Omit irrelevant 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 line items, we will also save the shopping items and automatically associate foreign keys. But the premise is that we need to set the relationship between them, that is, setSorders() in the forder, setForder() in the soorder, and properties in the entities corresponding to other related foreign keys.
Before, when we added the shopping item to the shopping cart, forder.setSorder(sorder) was executed. Now we need to add forder to the soorder, so we add it to the original code, as follows:
//This is the code in Section 17. 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 whether there are duplicate shopping items// Get the current shopping item Sorder soorder = productToSorder(product); //Judge whether the current shopping item is duplicated. If it is duplicated, add the quantity for(Sorder old: forder.getSorders()) { if(old.getProduct().getId().equals(sorder.getProduct().getId())) { //There are duplicates for shopping items, add the quantity old.setNumber(old.getNumber() + soorder.getNumber()); isHave = true; break; } } //The current shopping item does not exist in the shopping cart, if(!isHave) { //We insert a sentence here: //Before adding the shopping item to the shopping item, first establish the association between the shopping item and the shopping cart, but at this time forder.id is null, //But when entering the warehouse, you first enter the warehouse shopping cart and then enter the warehouse shopping item. At that time, there is the primary key soorder.setForder(forder); forder.getSorders().add(sorder); } return forder; } @Override public Sorder productToSorder(Product product) { Sorder soorder = new Sorder(); soorder.setName(product.getName()); soorder.setNumber(1); soorder.setPrice(product.getPrice()); soorder.setProduct(product); return sorder; } }OK, let's take a look at which Action to jump to when the order confirms:
So we go to complete the logic in the forderAction:
@Controller("forderAction") @Scope("prototype") public class ForderAction extends BaseAction<Forder> { @Override public Forder getModel() { model = (Forder) session.get("forder"); return model; } //Implement the cascaded storage function of shopping cart (order) and shopping items (line items) public String save() { // // Hand the shopping items in the session to the current model object// 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()); //forder.setPost(model.getPost()); //forder.setUser((User)session.get("user")); //forder.setStatus(new Status(1)); //forder.setPost(model.getPost()); // //Cascaded library (need to be configured in the annotation of xml or POJO), so the soorder association forder is required // //Add to the SorderServiceImpl class.setForder(forder); //ForderService.save(forder); model.setUser((User)session.get("user")); model.setStatus(new Status(1)); forderService.save(model); return "bank"; } } As can be seen from the above code, there are two methods: the first is not overriding the getModel method (the part I commented out). This method is quite stupid. Since ForderAction inherits BaseAction, and BaseAction implements the ModelDriven interface, the data passed will be encapsulated into the model. Model is a property in BaseAction. Then we need to pass all the information in the model to the forder in the session, and then the data in the forder can be cascading with Sorder to enter the library. However, this method is a bit stupid... So we use the second method, rewrite the getModel method, and directly assign the forder to the model, and then we just need to add the cascading items in the model, that is, the non-annotated code above. In this way, after the user clicks to confirm the order, the information will be entered into the database and jump to the payment page (the payment page needs to be done next, so you can just jump to a jsp first).
2. Page caching issues
Now the cascading entry of the order information has been solved, but if the user clicks to confirm the order and then back, we find that it is still the original order confirmation page, and the information is still the information just now, and the session is not closed, which means that I have to confirm the order information again, which is obviously inappropriate. In other words, when the user clicks to confirm the order, we cannot let the page cache. In this way, when the user clicks to back, it will show that the page has expired, and we just let it jump to the homepage.
We know that the front-end jsp page can be set so that the browser does not cache data, so we can set it as follows on the front-end confirm.jsp page:
But the problem is not that simple. Just doing this is not possible. If you do this, the user clicks back and will prompt that the page has expired. However, when the user refreshes it and it is not possible, the cache will be loaded with the original data. So we understand one thing. Since the session has not been closed yet, there is an order information for the forder in the session. Users will definitely continue to get this forder after refreshing it, and the original order information will be displayed. Therefore, setting this in the front desk cannot solve the problem at all. We also need to do relevant processing in the background.
Since we know the problem, we can do this: because when the user clicks to confirm the order, it will hand it over to ForderAction, and then after the ForderAction is processed, it will jump to the payment page. We can do some tricks in ForderAction: We clear the original forder in the session, isn't that OK? This is feasible, but considering that the order is still relevant to the order when making payments later, we can save the original forder in the session to another place and clear the original forder. So we add two lines of code to the above ForderAction, as follows:
@Controller("forderAction") @Scope("prototype") public class ForderAction extends BaseAction<Forder> { @Override public Forder getModel() { model = (Forder) session.get("forder"); return model; } //Implement the cascaded storage function of shopping cart (order) and shopping items (line items) public String save() { // // Hand the shopping items in the session to the current model object// 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()); //forder.setPost(model.getPost()); //forder.setUser((User)session.get("user")); //forder.setStatus(new Status(1)); //forder.setPost(model.getPost()); // //Cascaded storage (need to be configured in the annotation of xml or POJO), so the soorder is associated with forder // //Add to the SorderServiceImpl class.save(forder); //ForderService.save(forder); model.setUser((User)session.get("user")); model.setStatus(new Status(1)); forderService.save(model); //The shopping cart has been stored in the storage, so the shopping cart in the original session should be cleared session.put("oldForder", session.get("forder"));//Save the original shopping cart information first, because relevant information is required when making payment later session.put("forder", new Forder());//New A new empty shopping cart (equivalent to clearing the shopping cart), which can also facilitate users to buy again~ return "bank"; } }Then, we have to add the following code to the front desk confirmation page:
The logic now is clear. First, when the order confirmation page, the forder has data, so it is not empty. This judgment is invalid. When the user clicks to confirm the order, in ForderAction we replace the forder with an empty Forder object, which means that the original data is gone (we save it in another key-value pair in the session for later payment). In this way, when the user clicks back and returns to the order confirmation page just now, the judgment takes effect and will jump to the homepage. At this point, the whole logic is complete and the page cache problem is solved.
Original address: http://blog.csdn.net/eson_15/article/details/51433247
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.