2016-07-22 25 views
8

Gegeben ein <p:dataTable> Rendern von Bildern in einer der Spalten.PrimeFaces 6.0 speichert keine Bilder auf der Client-Seite

<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> 

Die Datentabelle andere wesentliche häufigsten verwendete Attribute und Spalten enthält, wie und bei Bedarf.

Wenn diese Tabelle (Ajaxically) aktualisiert wird, werden alle Bilder abgerufen aus der Datenbank (oder Plattendateisystem, falls verwendet), als ob sie gar nicht durch den Browser zwischengespeichert werden, obwohl cache explizit auf true gesetzt (was ist der Standardwert). Dies funktionierte bisher gut mit PrimeFaces 5.3 final.

The migration guide gibt nichts darüber, aber anscheinend wurde etwas über das Caching <p:graphicImage> geändert.

Irgendwelche Vorschläge, um das Problem zu beheben? Wenn im obigen Beispiel die Tabelle 5 Bilder in 5 Zeilen enthält, wird die Datenbank bei jedem einzelnen Update, das an <p:dataTable> (mit Ausnahme der Inline-Zeilenbearbeitung, die standardmäßig auf die aktuelle Zeile verweist), 10 mal abgefragt sollte nicht passieren, da Bilder besonders aus einer Datenbank sehr teuer sind.


Request/Response-Header PrimeFaces 6.0 final (läuft auf Wildfly 10.0.0 final) verwendet wird, wenn eine erste Anfrage an den Server, um ein Bild zu dienen (funktioniert nicht - Bilder werden nicht zwischengespeichert).

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 

Request/Response-Header PrimeFaces 5.3 final (läuft auf Glassfish 4.1) verwendet wird, wenn eine erste Anfrage an den Server, um ein Bild zu dienen (funktioniert wie beabsichtigt - Bilder zwischengespeichert werden).

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 
+0

Haben Sie den Netzwerkverkehr der ersten Antwort untersucht? Irgendwelche Header, die eine nächste Anfrage anzeigen könnten, kommen nicht aus dem Cache? – Kukeltje

+0

Anforderungen zum Herunterladen von Bildern aus der Datenbank sind im HTTP-Netzwerkverkehrsmonitor sichtbar. Im Netzwerk-Traffic-Monitor sind separate Requests aufgelistet und alle Images werden jedes Mal von der Datenbank abgefragt, wenn eine AJAX-Anfrage zur Aktualisierung des angegebenen '' gemacht wird, die auch auf der Serverseite sichtbar ist, indem die entsprechenden vom Hibernate-Log generierten SQL-Statements angezeigt werden . – Tiny

+0

Ich Fleisch die HTTP-Cache-Header ... ist "etwas" vorhanden? Falsche Werte? – Kukeltje

Antwort

10

Header sehen gut aus. Dies deutet darauf hin, dass sich etwas in Abfragezeichenfolgenparametern von Anforderung zu Anforderung ändert. Dies würde auch als eine brandneue Ressource interpretiert werden und somit die Zwischenspeicherung vereiteln, obwohl der Basis-URI (der Teil vor dem URL-Abfragezeichenfolgentrennzeichen ?) genau gleich ist.

Und in der Tat hat PrimeFaces 6.0 die Art und Weise geändert, wie der Abfragezeichenfolgenparameter pfdrid generiert wird. Es ist eine völlig zufällige UUID geworden, die sich jedes Mal ändert, wenn der HTML <img src> gerendert wird. Siehe auch line 59 of PF 6.0 source code. In PrimeFaces 5.3 wurde es basierend auf der EL-Ausdruckszeichenfolge verschlüsselt und ist somit garantiert für alle Anfragen gleich, solange die EL-Ausdruckszeichenfolge gleich ist. Siehe auch line 53 of PF 5.3 source code.

Die Änderung war introduced von Cagatay ohne einen Verweis auf ein Problem Ticket. Es bleibt also unklar, warum genau diese Änderung vorgenommen wurde. Aber schließlich bietet es dem Kunden nicht mehr die Möglichkeit, den dynamischen Inhalt zwischenzuspeichern und würde somit die Leistung in beiden Bereichen verringern. Dies ist definitiv ein Ausgabeticket bei PrimeFaces wert, also habe ich eins erstellt: issue 1765.

Ich sehe keinen sauberen Weg, dies zu lösen, als den PrimeFaces Quellcode zu hacken. Ihre beste Wette ist es, die <p:graphicImage> durch eine <h:graphicImage> mit einem "plain vanilla servlet" zu ersetzen, oder wenn Sie JSF-Dienstprogramm Bibliothek OmniFaces verwenden, dann die <o:graphicImage> mit einer einfachen Bean.Diese Ansätze sind bereits detailliert in dieser verwandten Q & A: Show image as byte[] from database as graphic image in JSF page beschrieben.


aktualisieren: wie pro issue 1765 es für PrimeFaces fixiert 6.1 wurde.

+0

Das Update von Problem 1765 wird den Fall nicht beheben, wenn Sie Bilder auf mehreren Seiten verwenden. Ich habe eine neue Folge geöffnet [Ausgabe 2097] (https://github.com/primefaces/primefaces/issues/2097) – Dominik