149-RESTful案例之处理静态资源

好，那我们的列表功能实现了之后啊，咱们可以给它加上一个样式，对吧？啊这列表呢，不太好看，那我们下面呢，大家来看一下咱们怎么做，咱们先来找到咱们的这个资源，对吧？大家注意，然后在这呢，然后咱们有个静态资源，有一个咱们常用的配置文件，然后这个static里面呢，有CSS，然后还有呢，就是咱们的这个GSX7QUERY，还有这个view的，然后呢，我们下面呢，这个因为我们一会在实现删除功能的时候，咱们要咱们要使用这个view啊，所以说呢，那我们就直接把咱们的这个static呀，然后把它复制放到我们当前的工程中，放到咱们的web APP下啊。好，那像这种情况的话，特别是我们中间复制过来的这些内容啊，我建议大家呢，重新去打一个包，为什么呢？因为很有可能啊，然后我们当前咱们的这个挂包下面，它是没有这个static的，对吧，然后我们现在可以先给它清理一下。

好，然后清理完之后，然后我们在这咱们再来一个重新打包，然后打完包之后，咱们就可以来保证我们当前咱们的这个挖包下面肯定是有这个static的啊，来大家看一下。好，大家看现在就有了，那我们是不是就可以直接来使用了，然后咱们直接在咱们的这个head里面对吧，然后来使用咱们的link标签来引入我们当前的CSS文件TH冒号。然后是A大括号，然后斜线怎么写static，然后斜线，或者说大家要不想去写这个路径的话，大家可以直接去复制，然后咱们来点击右键，这有一个叫做copy pass，然后咱们来选择第二个啊，然后把它复制过来，把多余的内容给它删掉就行，那我们现在咱们要访问的话，是不是直接从static下边来访问就行。对吧，因为咱们的这个APP啊，它只是来这个来存放我们当前咱们的静态资源的，然后在我们当前咱们的挂包里面，大家看一下有这个路径没有啊，没有，所以说咱们直接访问static是再访问static下面的内容就可以啊，行，然后下面我们来一个重新部署，大家看，那我们当前咱们的这个页面中，它会不会有这个样式的效果呢？大家注意它并不会有啊，为什么咱们来看一下。

这个问题啊，咱们就好好的来分析一下啊，首先你看咱们页面中直接报错，然后咱们的index下滑线work.css大家看一下它这是不是直接就是404呀，对不对？好，然后所以说我们现在这个资源呢，它是找不到的，为什么找不到，然后我们来看咱们的这个标签，然后里面有个ref属性来引入的是咱们CSS的路径，那大家说我们当前咱们是不是就要从浏览器向服务器发送一个请求来访问我们当前的CSS对不对？好，那所以说呢，我们在web点叉ML中咱们所配置的啊，大家看好spring VC的前端控制器，它来处理的请求是不是应该是咱们从浏览器向服务器所发送的所有的请求。

OK吧，好，然后咱们写的是斜线看到了吧，好，然后所以它只是这个匹配不到咱们的点GSP的这种请求，但是其他的请求是不是都可以匹配到，所以说我们当前咱们来访问这个CSS的这个请求是不是也会被dispatch solve来处理，对不对，对吧？那咱们当前dispatch of它是怎么来处理请求的，大家应该都知道吧，咱们是不是得在控制层，然后来写个请求映射，然后写个请求映射之后，保证我们当前的Y流属性值跟咱们要来处理的请求的请求路径一致，然后就可以通过这个控制器方法来处理这个请求，这个大家能听懂吧。好，OK，所以说为什么我们现在咱们访问不到，因为咱们的静态资源它是由dispat solve来处理的吗？不是呀，对吧，如果说大家去看到过我们的Tom KT的web点叉L的话，大家会发现其中有一个东西叫做default solve，这个东西它就是专门来处理我们当前的静态资源的，来大家看啊，我们来找到我们的这个E盘，然后把咱们当前的server给打开，找到咱们的Tom KD8.5，咱们找到框这个目录。

然后把外部的插苗给它打开，然后咱们来进行编辑。来大家看啊，然后我们之前呢，咱们是看了一个GSP solve的问题，然后下面呢，我们再来看一下咱们这个默认的solve的问题啊。然后我们往上走，大家看一下，你看这个默认的solve，它就是专门来处理谁的，来处理我们当前咱们的静态资源的，OK吧，好，然后我们来看一下我们当前的这个默认的solve，它的URL pattern是什么？来咱们CTRL加F，然后我们往下找，咱们再往下。对吧，然后大家看啊，往下找啊。Default of that。查找没问题啊，对吧？哦对，下面没有了，下面应该咱们搜的是deat对不对，因为咱们的solve mapping里面有solve name，但是它没有谁啊，没有这个solve class对不对，咱们往下找，再往下再往下再往下，大家注意啊，来咱们继续大家看，你看咱们就看见它了。

然后大家会发现，你看它设置的也是啥呀，斜线OK，那所以问题就来了，大家说这个web点叉L跟我们当前咱们工程里面的web点差没它们两个之间有啥关系啊。大家想一下，这个web点差苗是tomcat的，所以说Tom catt的web点差苗是作用于我们当前部署到tomcat中的所有的工程的，而我们当前呢，咱们的工程的web点差苗只作用于我们当前的工程本身好，所以说他们两个逻辑上咱们可以这样认为，他们逻辑上是一个继承的关系，也就是说我们当前这个web点叉L里面的内容会全部都继承给我们当前咱们工程的web点叉L。

为什么你访问上下文路径，它会默认访问index.html或者index.gsp那不就是因为在我们的这个配置文件中，咱们最后来设置的有一个欢迎文件的列表吗？对不对？然后当我们访问上下文路径，它会默认先找他找不着再找它，找不着再找点GSP，对不对？所以说大家一定要看好，就他们两个之间的关系啊，他们两个之间的关系是逻辑上的继承关系，也就是说这个配置文件中的内容会全部都继承给我们当前工程的web点查苗，那所以说大家想一下，那如果他俩要是你，比如说我现在，哎，我的这个，呃，Tom cat的web点叉L中我配置了某个内容，然后我的这个工程的web点叉L我也配置了某某个内容，也就是说，当他们两个配置的冲突的时候，那我们以谁为准，以我们当前的工程为准呢？比比如说咱们欢迎文件列表，如果我们现在在自己的工程里面，咱们来写了一个welcome-fair-list，我们在这来写了一个test.html大家注意这是啥意思，这个是什么意思呀？这个来表示的是我们访问上下文路径默认要访问谁test.hml那这个时候我们当前Tom k的web.L中的这个配置还有用吗？就没有用了，也就是说如果Tom k的web点叉L中的配置跟咱们的工程的web点叉L的配置它俩要是冲突的话，咱们以谁为准？

以我们当前工程的配置为准为准，好，那所以大家看我把这个东西给删掉，那大家有没有发现咱们当前不同的solve，它的URL pattern冲突了。它是斜线，大家会发现咱们这个地方它也是啥也是斜线，那所以说它是不是可以对我们当前咱们的这个浏览器所发送过来的所有的请求来进行处理，然后我们当前咱们的这个是不是也会对所有请求进行处理，对不对，那所以他俩冲突的之后以谁为准，以我们当前工程的配置为准，所以说我们当前所有的请求都会被谁进行处理，Dispatch solve that进行处理，但是他能处理静态资源吗？处理不了，我们要想处理静态资源，我们应该用的是默认的solve，能听懂吧，所以说大家注意，为什么咱们现在咱们来使用了静态资源，结果的不好使，报404，为啥？因为我们默，咱们的静态资源，咱们应该是由默认的solve来处理的，结果呢，咱们的默认的它的配置的URL pattern跟咱们自己配置的dispat solve的URL pattern冲突了，那冲突了之后以谁为准，以我们当前咱们工程。

成的外边的差苗为准，所以说现在的静态资源也是由他来处理的，但是他能处理的了吗？处理不了，所以说就是404OK吧，有藤老师，那我之前我原来在学习solve let的时候，他为啥不冲突，那简单呀，因为我们之前学的solve，你的路径都是一个固定的路径，具体的路径，那所以说它肯定是先找到咱们自己的web点叉L，然后通过我们的请求路径跟URL pattern去匹配，匹配成功由我们当前咱们的这个solve来处理，对不对，由我们自己创建的solve来处理，而如果我们当前咱们所发送的请求的请求路径跟我们在当前工程的web点叉L中的URL pattern它们两个如果不匹配的话，那咱们是不是需要去找谁了，找我们当前咱们的Tom cat的web点叉中的配置，然后进行处理了，OK吧，好，这个时候我们应该怎么解决这个问题，大家看啊，我们来找到咱们spring VC的配置文件，然后咱们。

要在这里面呢，来加上一个新的配置，叫什么配置，大家看啊，我在这来写一下，好，然后咱们是通过来配置咱们默认默认的serve that，然后来处理静态资源，OK，怎么写啊，叫做MVC冒号default serve that-handler。

大家注意，这个就是来配置默认的solve来处理静态资源的，但是大家看好这个标签啊，可不是说你把它配置出来它就有用的，因为我们如果大家听好，如果你只配置这个标签的话，或者说咱们这样说，咱们从头开始说啊，如果你不配置这个标签，我们当前所有的请求都是被dispatch solve来处理的，而如果我只配置这个标签，那我们当前咱们所有的请求将全部都被默认的来处理。但是大家都知道默认的solve light可以处理静态资源，那我们自己写的那些请求是不是都要被dispatch solve处理啊？所以说我们现在把这个标签配置上之后，你光配置它不不行，我们还得干嘛，咱们还得把这个开启MVC的注解驱动，把它给配置上，知道不？这个时候你配置的这两个标签才会有什么效果，它的效果才是我们当前的请求先由dispatter solve处理，如果它处理不了，然后咱们再让默认的solvel来处理。

能听懂吧，好，OK，这个大家注意啊，因为我们当前你看咱们的这个东西的话，我们对吧，然后我们当前咱们的这个内容，咱们是因为视图控制器咱们加上的，对不对，但是大家也要知道，如果你现在你不用视图控制器，我们当前如果你不用视图控制器，那我们当前咱们在使用默认的solve处理静态资源的时候，它也是需要来开启MVC的注解驱动的，OK吧，行，这个大家注意啊，好OK，那我在这儿呢给大家写一下好。行，然后为什么咱们要配置它，大家注意啊，那是因为然后咱们当前工程，当前工程的外部点叉ML对吧，然后咱们去配置的前端控制器啊，叫做前端控制器dispat solve的URL杠杠，P pattern，然后为斜线啊，然后是斜线。

是。斜线好，然后咱们的Tom cat。的web点叉L的web点叉L配置的默认的solve let，配置的deft solve let对吧，然后它的URL pattern，它也是什么，它也是斜线。也是斜线对吧，好，然后呢，此时。好，然后咱们浏览器发送的请求，对吧，因为他俩冲突了，那所以说以谁为准，当前的浏览器发送的请求，然后会优先被谁来处理，然会优先对吧，然后被咱们的dispatch ofle，然后来进行处理，进行处理。

能看懂不好，OK，然后这个时候大家说咱们的这个静态资源它能处理，处理的了，不处理不了啊，然后但是对吧，然后咱们的dispatch of that，然后他无法来处理咱们的静态资源，OK，那这个时候怎么办？大家注意啊，好，然后那若咱们配置了哪个标签叫做default-so let-handle了，如果咱们配置了这个标签，那此时咱们浏览器发送发送的所有请求，对吧，然后所有请求然后都会被谁来处理，Default solve，然后来进行处理。OK吧，好，然后大家看好，那咱们若配置了谁和谁，若配置了default杠，Solve杠，Handle，然后和咱们的MVC杠。MVC冒号gun driver，如果咱们配置的这两个，然后咱们浏览器发送的请求，浏览器发送的请求，发送的请求然后会先被谁会会先先被咱们的这个先被，然后dispature solve that，然后来处理，处理不了对吧？然后无法处理，无法处理处理然后再交给谁来处理咱们默认的solve that default solve that，然后来处理，OK。

像这个大家注意啊，好，然后那所以大家可以去测试一下，或者说大家直接记住这个结论，如果你要想用默认的solve处理静态资源，那我们就要把这个标签设置上，大家还要把这个标签设置上，OK吧，然后大家要想去测试的话，你把这两个标签给它删掉，然后大家会发现一个问题啊，你不要光删这个标签啊，你光删这个标签，因为你有视图控制器，所以说你也只有我们当前视图控制器所设置的请求会被处理，其他的请求也处理不了啊，所以说大家可以把这两个都给它删掉，删掉之后你会发现只有静态资源能被处理了，那咱们自己写的请求能被处理吗？处理不了，而只有大家把这个给加上我们当前自己写的请求，还有静态资源，它都可以被处理了，OK吧，好，为什么？因为当我们把这两个都配置上之后，它是先被dispatch solve处理，处理不了，咱们再会把当前的请求交给咱们的disloult solve来处理，哎。

行啊好，那我们现在咱们配置完了，下面我们在这咱们再来一个重新部署，大家看啊，这个时候我们的页面里面咱们就有这个效果了，OK吧，然后现在我们来一个刷新啊刷新。大家看看咱们的样式是不是就出来了呀，对不对，好，大家注意，这就是我们处理静态资源的一个方式啊好。