PrimeFaces 6.0不上給出的一列的<code><p:dataTable></code>繪製圖像客戶端

Question

緩存圖像。

<p:dataTable id="dataTable" var="row" value="#{bean}" 
      lazy="true" 
      skipChildren="true"> 

    <p:column headerText="Image"> 
     <p:cellEditor> 
      <f:facet name="output"> 
       <p:graphicImage value="#{imageBean.image}" stream="true" cache="true"> 
        <f:param name="id" value="#{row.id}"/> 
        <f:param name="width" value="100"/> 
        <f:param name="height" value="100"/> 
       </p:graphicImage> 
      </f:facet> 

      <f:facet name="input"> 
       <p:graphicImage value="#{imageBean.image}" stream="true" cache="true"> 
        <f:param name="id" value="#{row.id}"/> 
        <f:param name="width" value="100"/> 
        <f:param name="height" value="100"/> 
       </p:graphicImage> 

       <!-- <p:overlayPanel> here for file upload --> 
      </f:facet> 
     </p:cellEditor> 
    </p:column> 

    <p:column headerText="Edit"> 
     <p:rowEditor/> 
    </p:column> 
</p:dataTable> 

_{數據表可能包含其他必要的常用屬性和列在需要時。}

當此表（Ajaxically）更新，所有圖像都是從數據庫中提取（或磁盤的文件系統，如果使用的話），因爲如果他們不被瀏覽器緩存，即使cache明確設置爲true（在所有這是默認值）。 PrimeFaces 5.3的最終版本在此之前運行良好。

The migration guide規定一無所知，但顯然事情已經改變了對緩存<p:graphicImage>。

任何建議來解決這個問題？

在上面的例子中，如果表格包含5行5個圖像，例如，在對<p:dataTable>進行的每次更新（除了內聯行編輯默認爲當前行）之外，將對數據庫查詢10次不應該發生，特別是從數據庫獲取圖像是非常昂貴的。使用PrimeFaces

---

請求/響應頭6.0最後，當初始請求到服務器提供的圖像由（上WildFly 10.0.0最終運行）（不工作 - 圖像不被高速緩存）。使用PrimeFaces 5.3最終

General 
    Request URL:https://localhost:8443/ContextRoot/javax.faces.resource/dynamiccontent.properties.xhtml?ln=primefaces&v=6.0&pfdrid=aed903cc-daba-4822-a62b-888b9a0ef2ac&pfdrt=sc&id=14&width=100&height=100&pfdrid_c=true 
    Request Method:GET 
    Status Code:200 OK 
    Remote Address:127.0.0.1:8443 
Response Headers 
    Cache-Control:max-age=29030400 
    Connection:keep-alive 
    Date:Sat, 23 Jul 2016 06:59:54 GMT 
    Expires:Sun, 23 Jul 2017 06:59:54 GMT 
    Server:WildFly/10 
    Transfer-Encoding:chunked 
    X-Powered-By:Undertow/1 
Request Headers 
    Accept:image/webp,image/*,*/*;q=0.8 
    Accept-Encoding:gzip, deflate, sdch 
    Accept-Language:en-US,en;q=0.8 
    Connection:keep-alive 
    Cookie:JSESSIONID=4AoRGa1IAPTB4KssnikbO9uUetcQpMupli8BkGga.om-f6b0ea3ad206; __utma=111872281.616526714.1454485589.1468749319.1468751735.4; __utmz=111872281.1454485589.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) 
    Host:localhost:8443 
    Referer:https://localhost:8443/ContextRoot/admin/Brand 
    User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 
Query String Parameters 
    ln:primefaces 
    v:6.0 
    pfdrid:aed903cc-daba-4822-a62b-888b9a0ef2ac 
    pfdrt:sc 
    id:14 
    width:100 
    height:100 
    pfdrid_c:true 

---

請求/響應報頭中，當初始請求到服務器提供的圖像（ - 圖像被緩存按預期工作）製成（在GlassFish 4.1運行）。

General 
    Request URL:https://localhost:8181/ContextRoot/javax.faces.resource/dynamiccontent.properties.xhtml?ln=primefaces&v=5.3&pfdrid=aAPHlxcQ2lcqfvzacYoCC6iUxLU1VVFp&pfdrt=sc&id=11&width=100&height=100&pfdrid_c=true 
    Request Method:GET 
    Status Code:200 OK 
    Remote Address:127.0.0.1:8181 
Response Headers 
    Cache-Control:max-age=29030400 
    Date:Sat, 23 Jul 2016 07:15:03 GMT 
    Expires:Sun, 23 Jul 2017 07:15:04 GMT 
    Pragma:No-cache 
    Server:GlassFish Server Open Source Edition 4.1 
    Transfer-Encoding:chunked 
    X-Powered-By:Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1 Java/Oracle Corporation/1.8) 
Request Headers 
    Accept:image/webp,image/*,*/*;q=0.8 
    Accept-Encoding:gzip, deflate, sdch 
    Accept-Language:en-US,en;q=0.8 
    Connection:keep-alive 
    Cookie:JSESSIONID=69b5070218cfe0fc6eaac2141c13; __utma=111872281.616526714.1454485589.1468749319.1468751735.4; __utmz=111872281.1454485589.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) 
    Host:localhost:8181 
    Referer:https://localhost:8181/ContextRoot/admin/Brand 
    User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 
Query String Parameters 
    ln:primefaces 
    v:5.3 
    pfdrid:aAPHlxcQ2lcqfvzacYoCC6iUxLU1VVFp 
    pfdrt:sc 
    id:11 
    width:100 
    height:100 
    pfdrid_c:true 

Answer 1

標題看起來不錯。這表明查詢字符串參數中的某些內容從請求變爲請求。這也將被解釋爲一個全新的資源，因此即使基礎URI（URL查詢字符串分隔符?之前的部分）完全相同，也會破壞緩存。

事實上，PrimeFaces 6.0改變是如何產生的pfdrid查詢字符串參數的方式。它已成爲一個完全隨機UUID從而改變每次當HTML <img src>渲染的時候。另見line 59 of PF 6.0 source code。在PrimeFaces 5.3中，它是基於EL表達式字符串進行加密的，因此只要EL表達式字符串相同，就可以保證在所有請求中都是相同的。另請參閱line 53 of PF 5.3 source code。

的變化是由introduced沒有Cagatay一個問題票的參考。所以目前還不清楚爲什麼這個改變完成了。但畢竟它不能爲客戶提供緩存動態內容的機會，因此實際上會降低兩端的性能。這絕對是值得PrimeFaces問題的一張票，所以我創建了一個：issue 1765。

我沒有看到一個乾淨的方式來解決這個問題，而不是黑客入侵PrimeFaces源代碼。你最好的選擇是用<h:graphicImage>替換<p:graphicImage>用「普通香草servlet」，或者如果你碰巧使用JSF實用程序庫OmniFaces，那麼用一個簡單的豆<o:graphicImage>。這些方法都已經詳細介紹在此相關Q &答：Show image as byte[] from database as graphic image in JSF page。

---

更新：根據issue 1765，它已被固定PrimeFaces 6.1。