PrimeFaces 6.0 nie buforuje obrazów po stronie klienta.

Question

Przy renderowaniu obrazów w jednej z kolumn.

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

_{tabela danych może zawierać inne istotne powszechnie używane atrybuty i kolumny, jak i gdy są potrzebne.}

Gdy tabela jest (Ajaxically) aktualizowany, wszystkie obrazy są pobierane z bazy danych (systemu lub plików na dysku, jeśli jest stosowany), a jeśli nie są buforowane przez przeglądarkę w ogóle chociaż cache jest jawnie ustawione true (która jest wartością domyślną). To działało dobrze wcześniej niż PrimeFaces 5.3 final.

The migration guide nic o tym nie mówi, ale najwyraźniej coś zostało zmienione o buforowaniu <p:graphicImage>.

Wszelkie sugestie dotyczące rozwiązania problemu?

W powyższym przykładzie, jeśli tabela zawiera 5 obrazów w 5 wierszach, na przykład baza danych będzie sprawdzana 10 razy przy każdej aktualizacji wykonanej do <p:dataTable> (z wyjątkiem edycji wiersza w wierszu domyślnie bieżącego wiersza), nie powinno się zdarzyć, ponieważ uzyskiwanie obrazów, szczególnie z bazy danych, jest bardzo kosztowne. Nagłówki

---

żądanie/odpowiedź wykorzystujące PrimeFaces 6,0 końcowy (uruchomiony na JBoss Application Server 10.0.0 końcowego), gdy początkowy wniosek został złożony do serwera, aby służyć obrazu (nie działa - zdjęcia nie są buforowane). Nagłówki

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 

---

żądanie/odpowiedź wykorzystujące PrimeFaces 5.3 final (działa na GlassFish 4.1), gdy wstępny wniosek został złożony do serwera, aby służyć obrazu (działa zgodnie z przeznaczeniem - zdjęcia są buforowane).

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

Nagłówki dobrze wyglądają. Sugeruje to, że coś w parametrach ciągów zapytania zmienia się z żądania na żądanie. Zostałoby to również zinterpretowane jako zupełnie nowy zasób i tym samym zniweczyć buforowanie, mimo że podstawowy identyfikator URI (część przed separatorem ciągów znaków zapytania URL ?) jest dokładnie taki sam.

Rzeczywiście, PrimeFaces 6.0 zmieniło sposób generowania parametru ciągu zapytania pfdrid. Stało się całkowicie losowe UUID, które zmienia się za każdym razem, gdy HTML <img src> jest renderowane. Zobacz także line 59 of PF 6.0 source code. W PrimeFaces 5.3, był zaszyfrowany w oparciu o ciąg wyrażeń EL, a więc gwarantowany był taki sam dla żądań, o ile ciąg wyrażenia EL jest taki sam. Zobacz także line 53 of PF 5.3 source code.

Zmiana nastąpiła introduced przez Cagatay bez odniesienia do biletu wydania. Nie jest jasne, dlaczego dokładnie dokonano tej zmiany. W końcu jednak nie oferuje on klientowi możliwości buforowania zawartości dynamicznej, a tym samym zmniejszenia wydajności w obu końcach. Jest to zdecydowanie warte wydania biletu na PrimeFaces, więc stworzyłem jeden: issue 1765.

Nie widzę czystej metody rozwiązania tego problemu poza hackowaniem kodu źródłowego PrimeFaces. Najlepiej jest zastąpić <p:graphicImage> przez <h:graphicImage> "zwykłym serwletem waniliowym" lub jeśli używasz biblioteki narzędziowej JSF OmniFaces, a następnie <o:graphicImage> z prostą fasolą.Te podejścia są już szczegółowo opisane w tym powiązanym Q & A: Show image as byte[] from database as graphic image in JSF page.

---

Aktualizacja: zgodnie issue 1765, została ustalona dla PrimeFaces 6.1.