Quickly copy the current code to the next line: ctrl+D
Format code (quickly organize code): ctrl+alt+L
Step by step, the follow-up will continue to add features.
Create the project structure first: build the framework
Problems with the implementation of login and registration functions:
Logging in is very simple, so I won't go into details here. You can refer to the content of the previous blog, which contains an introduction to login.
Mainly look at the problem of registration:
The first problem: without judging whether the data is empty, the data is inserted into the database. At this time, the inserted data is all null.
Reason: via logger.ingo("user"). we can find out that. It turns out that our judgment statement is:
if(user == null) . But the user output in the log is a po.user type, and each data stored in it is null. But not user is null.
Modification: Change to user.getAccount() == null
Second problem: inserted three times
Inside the insert statement, it is inserted three times. Because, in this, three insertions are used (userDao.register (user) despite)
Modification: save only one userDao.register statement.
The third question: the data submitted to the Controller from the form. The attribute specification of the model is required.
When the browser enters /register, its modelAttribute is user. Indicates that the form it submits will have a model attribute of user. So modify it as below.
The fourth question: the data submitted from the service layer to the view layer. Also need to have the corresponding model attribute specified
Like below, the service layer returns to login.jsp. Then login.jsp exists modelAttribute("login"). So the model attribute of login must also be specified here.
The third and fourth problems are to submit data from two directions respectively. If the above attributes are not specified, it will cause the browser to 500 and prompt that the bean tag cannot be found.
The fifth question: It is about the attribute specification of the database.
For example, the specified id here cannot be empty, so. In the Mapper.xml file, you need to assign a value to the id in the sql statement first, otherwise, an error will be reported.
For example, here, you must first assign null.
The second function: realize the display of commodity types and the addition of commodity types.
First question: 404
Both the commodity type and the addition of commodity types belong to a table of commodity types. Then when I was doing it, I put the SQL statement in the UserMapper.xml file (the mapping of the UserMapper.xml file is dao.userDao.) It does not match the table we belong to the product type.
Modification: A Mapper.xml of commodity type needs to be created. Need to create a POJO type commodity type. Add a mapping to the commodity type in the mybatis-config.xml file.
After the modification, the 404 problem will not appear.
The second question: It is not recommended to write more code layers. A table corresponds to a type of code layer. For example: the type of product this time. Then write GoodsType. (dao layer is TypeGoodsDao, service layer is TypeService, controller layer is TypeController)
Regarding the code layer, my initial approach was to divide it into two modules, one for adding and one for display. But the requirement in the book is to display it on the same page, and it gets more and more messy in the end. Until I deleted all the code in the code layer and put it in a module again to think about it, the problem was solved.
The third question: I want to know how data is transmitted and stored in this.
Summarize your insights:
1. The method parameters of the Controller layer should correspond to the Service layer one by one.
2. Like SQL statements. If no data is transmitted from the view layer, the POJO type of the controller layer is always empty, and of course the Service layer is always empty. For example: query all statements. No view layer passes data. You only need to use the method of the dao layer in the view layer to get the data. But the POJO data is always empty.
3. If the data is passed from the view layer (the view layer data is bound to the properties of the POJO), then the POJO always has such a piece of data. There is only this one piece of data.
4. One thing needs to be paid attention to. If multiple functions are placed under the same page, then there will be multiple model attributes in the view layer. Then the method corresponding to the function will also have several model.add attributes corresponding to it.
(It does not correspond to a function, so only write one model attribute in a method. Because the interface returned finally has multiple model attributes, even though it is a functional method, it must also write all the model.add attributes in the returned interface. Otherwise, only write one model attribute, and when it returns to the interface at the end, an error will be reported because other model attributes cannot be found. It will also prompt that the bean is not found.)
The third function: realize the display and deletion of commodity types. (Add a delete after each type)
The first question: I found that I don't seem to know how to delete a product. (The deletion of the main product, how should the data be submitted to the controller, and then the controller will delete it)
I know the sql statement for deleting goods: delete from goodstype where id = #{id}
However, how should this id be obtained from the view layer.
Solution: Submit the id to the controller through the JavasScript function.
Then write below: By using the method of the function, submit the id data.
There are two ways to get this data in the controller:
The first one is obtained by Integer. (The browser enters the /delete interface for the first time, and delete is not clicked at this time, and the ID is null.)
The second is to use the SQL mapping file of the Mapper.xml file by using the goodsTypeDao method through POJO. After using this method, the stored data of goodsType will be changed.
Here we need to pay attention, that is, is it possible to delete data only through the second method?
The answer is of course not:
Because we pass where id = {#id} in the SQL mapping statement.
That is, in the Dao layer, delete data is used in the way of delete (Integer id). Therefore, the first method must be used to obtain the transmitted id.
Comparison: We used query statements and insert statements earlier. Their type is POJO type.
Query and insert methods: they are bound with the POJO type in the form of a form, so just submit the action button. Will change the type of POJO. This is a bit different from how we use delete.
The way we click to delete here is to pass in the data of an id. Then pass it to the Service layer.
Summary: After writing this example, I almost understand how data is transmitted in these code layers.
For example: delete, by passing the id number. Use the mapping of the service layer.
Querying and adding are through binding with POJO. When the button is clicked, the data of POJO will be changed, and then passed to the Service layer, using the mapping of the dao layer.
The second problem: Click the delete button, the page does not change, but the database shows that the data has been deleted.
Summary: Start learning from the book "Introduction to JavaEE Framework Integrated Development to Practical Combat".
Up to now, I have learned Chapter 20, the design and implementation of the last e-commerce platform. I have encountered many difficulties along the way, until now, maybe I should change my mind and study. This book is not very good. Because of the last project, in my opinion, many places have not been explained clearly, for example, how their data is transmitted, and how suddenly, one interface gets another data. And a lot of data and attributes are missing.
I only figured out that the corresponding view layer obtains or passes in data through a model attribute. There are still many places that I don't understand. For example, when implementing the third function, uploading pictures, I encountered difficulties. Looking at the examples in the book, I really feel a little inexplicable.
In the end, we can only implement a simple add product category, but we cannot upload this interface. So this book ends here.
Of course, this book has given me a lot of gains. I have at least learned the basic construction of the SSM project and learned to use the IDEA application.