00:00
好,那这个restful案例增删改查呢,咱们就讲完了对吧?然后呢,那咱们再来简单的回顾一下,那咱们的列表页面呢?然后咱们是不是应该用的是employee这个请求地址对不对?请求方式呢,是get,然后我们就可以来实现查询所有员工信息的功能了,好,然后删除的时候呢,咱们比较麻烦,删除的时候咱们是不是用了咱们的view.rgs,对不对?然后用的是view,好然后通过咱们的超链接,然后去控制一个表单的提交,然后我们为这个超链接呢,然后来绑定了一个点击时间,通过view来处理这个点击时间,没问题吧,Form表单是不是才是我们最终提交请求的方式,对不对,对吧?咱们用的是超链接提交的方式吗?不是啊,咱们是不是在这里面做了一个操作,是不是叫做even.prevent default是不是啊,Prevent是不是应该是阻止的意思。是不是对吧,叫做阻止它的默认行为,好,那这个时候他就会按照我们上边所设置的提交表单的方式来提交请求了啊好,这个大家要注意好,再往下,那咱们的添加功能直接跳转到咱们的添加页面,然后咱们的修改功能呢,要跳转到修改页面,并且将咱们当前的请求方式是不是设置为put,没问题吧,好,增删改查里面就删除,稍微有些麻烦啊,这个大家要多下去练习一下,OK吧,哎,好啊,行,然后那我们下面咱们来说一下,就我们刚才在处理静态资源的时候,咱们的view.gs是不是有两次是找不到的,大家有印象没有,首先第一次给我们报的就是404,那为什么是404呢?是因为我们最后才添加了咱们的static,然后下面有一个GS,最后再把咱们的view.gs给它添加进去了,而在此之前我们当前的工程是不是已经运行过了,对不对,对吧,所以说我们。
01:58
之后添加进去的资源有没有存在于我们当前咱们打包之后的结果里面啊,没有,所以说咱们需要重新打包,能听懂吧?好,然后等到咱们重新打完包之后,当我们再次来实现这个功能的时候,大家会发现它还是找不到,那为什么找不到呢?大家注意,咱们来看一下咱们spring vc.xl,那是因为啊,我们的静态资源,咱们原来在外部阶段的时候,这个静态资源是交给谁来处理的呀?
02:29
啊,咱们的静态资源是交给谁来处理的,是交给默认的solve来处理的,知道吧,这个东西大家可能没有见过来,大家看好啊,这个是我们当前的tomcat,然后咱们tomcat中是不是有一个框文件夹里面来放的是咱们的配置文件,对不对?咱们把这个web点叉L啊,咱们给它打开,首先大家知不知道咱们默认的这个就是Tom cat里面的web点叉L,然后跟我们自己工程中的we部点差M苗是什么关系,大家知道不?
03:03
就相当于一个继承关系,我们当前tomcat中的这个web点差苗是作用于部署到tomcat中的所有工程,能听懂吧,而我们当前咱们工程中的web点差L只针对于我们当前的工程,能听懂吧?好,那如果说我们当前工程中的配置跟我们tomcat里面web点叉ML中的配置,然后发生了冲突,以谁为准,就近原则,以当前工程为准,能听懂不能听懂不好,OK啊好,那所以大家来看,你看啊,咱们先来找到我们默认的solve,咱们往上找,再往上大家来看啊,好,在这个地方大家看有一个solve solve name叫啥,叫default是不是对吧?然后再往下这个地方是咱们solve的class,大家自己看看,是叫默认的solve不是。是不是叫default solve,对不对,对吧?好,然后大家看load on standup什么时候加载的,什么时候初始化,服务器启动时初始化,对不对?再往下咱们需要去看它的映射信息,来,往下走走走走到这,这个是咱们的GSPSO,这个是来处理我们对GSP的访问的,能听懂吧,能听懂吧,好,OK,然后咱们再往下走,然后走到这,大家看这不就是咱们默认的solve default solve的一个映射信息吗?对不对?大家看它的URL pattern是啥?是斜线,那大家记不记得我们当前咱们在自己的web的叉ML中是不是也注册了一个前端控制器dispa of,它的URL pattern是不是也是斜片呢?对不对?那咱们刚才不才说过,如果URL pattern它俩是一样的,那是不是就说明我们当前自己工程中的dispat跟?
04:58
跟咱们we部容器,也就是咱们tomcat里面配置的default of,它俩是不是冲突了呀?哎,大家说对不对,都是来处理所有请求的,能听懂吧?那既然冲突了,以谁为准?
05:13
以谁为准?我说过以咱们当前工程中配置的为准,能听懂吧?所以说当前所有的请求将全部都被谁来处理,Dispatch solve that处理,但是dispatch solve that它是怎么来处理这个请求的?是不是每一次都会把咱们的这个请求地址去咱们的控制器中去找到相对应的请求映射,大家说是不是,是不是,但是大家想你的控制器里面有写咱们访问静态资源的请求映射没有,没有,那不就找不到吗?那不就是404吗?大家说是不是,那所以说我们在咱们的配置文件spring mvc点叉ML里面来在哪呢?在这对吧,咱们加上这个标签,大家知道是啥意思了,不,什么意思,就是我们当前如果浏览器发送的请求disparter solve处理不了,然后就会交给我们当前咱们default solve来处理,能听懂吗?
06:14
好,当然大家注意啊,这两个标签看到了没?这两个标签要一块去用,知道吧,如果说你不用这个标签的话,听好了啊,我们当前所有的请求都将被dispatch solve处理,能听懂不能听懂不,如果你不配置springvc的MVC的注解驱动,那咱们所有的请求将全部被默认的dispa solve letter来处理,所以说如果你只配置这个标签而不配置这个标签的话,好使不好使不好使,我们当前只有静态资源能访问的了,咱们其他的请求映射还能访问的了吗?访问不了?好,当我们把这个标签加上之后,就是我们刚才所说的效果先被谁处理啊,Dis次PA solve处理,如果说他在匹配请求的时候没有找到请求映射,那当前的请求就会被。
07:14
那谁deat solve来处理,能听懂吗?能听懂吧,好OK啊行,这个大家要注意啊,好,然后呢,大家再看,那如果我当前呀,然后我来发送了一个请求,咱们的请求,对咱们的请求后边加个SSS,这能看懂啊,然后大家说这个时候是不是谁都处理不了啊,对不对?大家想这个时候我们来一个回车之后报的是404,那大家说这个请求的处理过程应该是啥?应该先被谁默认啊,先被dispatch solve处理,找不到请求映射,是不是去找谁咱们默认的solve来处理,大家说对不对,如果默认的solve也处理不了,那就是404呗,是不是啊,这个我也跟大家说了,我们当前因为有日制功能,所以说在我们的这个控制台里面,不管咱们是默认的solve处理找不到,还是咱们的spring VC在处理的时候找不到。
08:14
是不是在这都会给我们报一个什么,都会给我们显示出来,咱们最终匹配的一个结果对不对,但是如果大家注意,你要是不加日志功能的话,咱们默认的solvel来处理的时候,它就没有,它就不会显示这个效果,知道吧,不会显示默认的找不到的这个问题,但是咱们现在加上的日志,大家来看,你看他在这给我们说的是不是默认的solve http request handle是不是找不到啊,是不是啊,对吧?好,这个大家注意啊。然后大家看好,来,你看如果我们上边能找到的话,咱们用的是这个东西,咱们是用的这个东西,你看spring mvc斜线employee,大家说这个能找到不能,这个能找到不能,可以找到吧,那它能够找到是通过谁找到的,是通过咱们的request mapping handler mapping request mapping是咱们的请求映射,Handler mapping handler是处理,Mapping是映射,就要处理映射能看懂吧,是由spring m VC来解决的啊好,但是如果我们当前咱们的spring VC处理不了,就要交给默认的solve处理,而这个东西大家注意,这个东西可不是我就就是说这个东西显示在这个地方,并不是说咱们所使用的默认的solve light是属于solve,是属于spring中的内容吗?不是,而是我们当前调用默认的solve来处理静态。
09:48
资源,然后是由我们的这一个类来处理的,能听懂吗?所以说在这虽然给我们报的这个错是spring中的错,但是最终来处理静态资源的类,它同样是咱们的default solve that,能听懂不?而这个类只是起到了一个什么样的作用?
10:07
什么样的作用,就咱们刚才说的那个过程。Dispa solve处理不了的请求交给谁来处理啊?Default solve来处理能听懂不?哎,这个东西啊,Request default solve http request handler这个东西的作用就是我们刚才所说的那个问题,但是大家注意,可不是说咱们的静态资源就是它处理的嘛,是不是不是,而是由它来调用咱们默认的so来处理的,能听懂不?哎,好啊,行,那这个是我们默认默这个静态资源的一个访问啊,大家要注意,这俩东西必须同时加,你要加光加这个的话行不行?不行,你不加都是dispa of处理的,能听懂不?你要光加它都是谁?Deault of that处理的能听懂不?你只有加上它之后才会干嘛?先由我们当前dispa solve处理,如果处理不了,才会交给deault solve处理能听懂吗?能听懂吗?很好啊。
11:12
OK。
我来说两句