前面已經(jīng)用了幾篇文章詳細的講解了DynamicCSSFilter,現(xiàn)在我們來看他們是如何應(yīng)用到加載css資源文件的。

創(chuàng)新互聯(lián)公司專注于企業(yè)網(wǎng)絡(luò)營銷推廣、網(wǎng)站重做改版、涼山州網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁面制作、購物商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為涼山州等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

前提：

假定我們開發(fā)了一個theme叫platform-In-theme,它其中我們寫了一個main.css,并且在其中我們用@import url()語法包含了若干個其他css,其中有一個是forms.css,并且這個css是用Sass的語法規(guī)則寫的，我們來深入研究下加載這個2個css文件的異同。

調(diào)試分析：

首先，當頁面請求main.css的時候，因為它滿足DynamicCSSFilter的模式，所以進入processFilter()方法，由前面幾篇文章，很快的拿到requestURI,requestPath,contextPath等信息，

從這圖上可以很清楚的看到，這個realPath是在我們的tomcat服務(wù)器上的webapps目錄下的theme部署子目錄，所以說這個是正確的，我們的自定義theme都是部署在這個目錄上。

現(xiàn)在我們可以看下原始還沒有被解析的main.css長什么樣子：

很顯然，和我們設(shè)想的一樣，它就是作為一個總的css用來包含其他的css文件。

現(xiàn)在開始解析這個css 文件，調(diào)用的是DynamicCSSUtil類的parseSass()方法.

首先它在第用98行利用theme=_getTheme(request,c***ealPath)來

獲取當前theme,因為我們的站點使用了platform-In-theme,所以返回這個theme.

然后，它利用_isThemeCssFastLoad(request,themeDisplay)方法獲取我們是否啟用了fast load ,因為這里我們沒有啟用fast load,所以返回false.

然后在115行獲取c***ealFile的File對象，剛才講過了，這個theme在服務(wù)器的webapps的相應(yīng)theme目錄中。

然后調(diào)用SassToCssBuilder.getCacheFile(c***ealPath)方法

來獲取這個css資源文件對應(yīng)的緩存文件，它首先吧真實css資源文件的反斜杠"\\"全部替換成正斜杠"/",然后獲取最后一個正斜杠位置，這是用來區(qū)分文件路徑部分和文件名部分，然后它在中間插入.sass_cache.

(千萬注意，這次和上次說的$CATALINA_HOME/TMPDIR 下面的緩存數(shù)據(jù)文件完全不同，那個文件是用于直接返回到客戶端（如果存在并且最新）的最終css文件，如果使用那個文件，就壓根不會調(diào)用parseSass()方法，而這個緩存的是原始的css資源文件，它是在parseSass()方法中被調(diào)用的，所以用途不同)

所以獲得的緩存文件的路徑就是如下圖：

這里有個判斷，如果這個緩存文件存在并且是最新的，那么就不用調(diào)用jRuby解析，而是直接把這個緩存文件的內(nèi)容作為最終parseSass()的返回值，也就是作為最終解析完的普通css文件輸出，但是我們是第一次，所以沒有這個資源文件，只好老老實實走jRuby解析的過程。

(1)正式解析的第一步是調(diào)用SassToCssBuilder.parseStaticTokens(content)方法來吧一些靜態(tài)的符號替換掉:

很容易理解，就是把Sass中的一些特殊內(nèi)容替換掉，比如文本的寬度，高度，和輸入框的高度寬度。

在這一步完結(jié)后，我們的main.css不受到影響。

(2)正式解析的第二步是先通過getQueryString方法獲得請求字符串。

然后調(diào)用_propagateQueryString()方法進行操作：

這步驟的作用是對于每一個@import(url ...)導(dǎo)入的資源文件，都在后面加上請求字符串。所以在這一步之后，我們的main.css變?yōu)椋?/p>

和我們設(shè)想的一樣，所有的@import url 的url后面都附加了請求字符串。這是為了保證請求一致性（我猜的）

(3)正式解析的第三步就進入了jRuby解析引擎的內(nèi)核了，這是通過_parseSass私有方法來完成的：

從這里我們可以看出，它首先會構(gòu)造一個HashMap對象，然后把我們要解析必要的參數(shù)，比如被解析的Sass內(nèi)容(content)，css的真實路徑(c***ealPath)，在當前應(yīng)用使用的Theme的css路徑(cssThemePath)，sass的緩存位置(sassCachePath)都放在HashMap中，然后在第295行使用_rubyExecutor.eval()方法調(diào)用jRuby解析器（位于/webapps/ROOT/WEB-INF/lib/jruby.jar中）來解析這個Sass文件：

最后解析完的結(jié)果通過unsyncPrintWriter輸出而返回，對于我們的main.css來說，經(jīng)過這一步之后，結(jié)果還是一樣的。因為這文件大多數(shù)都是引入其他文件，并沒有Sass的語法，所以不受到j(luò)Ruby解析引擎的 影響。

(4)正式解析的第四步是吧@portal_ctx@和@theme_p_w_picpath_path@注解都替換成相應(yīng)的字符串,這個工作代碼如下：

我們的main.css中沒有這些標識符，所以不受到影響。

經(jīng)過以上4步之后，這個方法就返回了dynamicContent，我們可以看到，它最終 返回到瀏覽器后的結(jié)果和正式解析第二步的一樣：

以上我們講解的是對于main.css的資源訪問，我們現(xiàn)在來看下對于其中包含的某個用Sass寫的文件，比如說上面的forms.css，這個流程又是這么樣的。

其實大體上流程都一致：

我這里也想省略去多數(shù)重復(fù)的調(diào)試流程了，反正最終不一樣的就是正式解析的第3步，它會去調(diào)用jruby.jar中的解析引擎去完成具體的解析，所以我們開始這個forms.css文件的內(nèi)容是：

解析完成之后，這個文件內(nèi)容變?yōu)椋?/p>

總結(jié)：

(1)當單個加載Sass資源文件的時候，這種Sass資源文件都有可能有解析完的文件緩存在服務(wù)器上，并且緩存文件的位置一定在原始資源文件的上級目錄下的.sass_cache目錄下，并且文件名和原始Sass資源文件名字相同。

(2)正式解析的第一步是解析Sass文件中的靜態(tài)符號，比如@model_hints_contant....@

(3) 正式解析的第二步是吧所有Sass中的以@import url()形式給出的外部引入，其被引入的資源文件后面都加上請求字符串，這是為了保證其請求的一致性。

(4)正式解析的第三步是調(diào)用jRuby的解析引擎根據(jù)解析語法進行解析，它會吧所有的Sass語法替換為普通的css語法，這個解析引擎位于webapps/ROOT/WEB-INF/lib/jruby.jar jar包中

(5)正式解析的第四步是做一些收尾工作，吧一些靜態(tài)標識符@portal_ctx@和@theme_p_w_picpath_path@解析為字符串，因為在css文件中經(jīng)常會用到一些外部圖片參與到樣式中。

(6)對于main.css ,主要影響的是(3)

(7)對于main.css包含的某個css,如果它是用Sass語法寫的，那么主要受到影響的是(4)

(8)一般的css,如果頁面上有一些特殊的記號，那么受到(2)和 (5)影響。

當前題目：深入Liferay當頁面請求css資源利用parseSass()方法解析
分享路徑：http://chinadenli.net/article38/gsjopp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、Google、品牌網(wǎng)站制作、手機網(wǎng)站建設(shè)、網(wǎng)站排名、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)