rdebusscher
commented
9 years ago Not using the hashCode but the StringEncrypter utility class which is also used from PrimeFaces 4.x on. (copied from PrimeFaces 4.x as not present in 3.4 and 3.5)
Open 99sono opened 9 years ago
rdebusscher
commented
9 years ago Not using the hashCode but the StringEncrypter utility class which is also used from PrimeFaces 4.x on. (copied from PrimeFaces 4.x as not present in 3.4 and 3.5)
99sono
commented
9 years ago In the end the original expression that I proposed for generating the Id based on clientId and value expression revealed itself not to be good enough because it is too deterministic for a given veiw. I the head of the code branch you will see that these two elements are used to create a CanonIcal ID. The final ID that is sent to the browser ends up being a combination of the canonical ID plus a random seed which changes with every deploymend plus an increment number. The incrementing number goes up each time a new StreamContent is open, and keeps the old number when the stream content is closed. When you have an ID generated in such a way, you get the following: If the user refreshes the page, the algorithm is able to generate the exact same ID that it had generated before, so it can continue feeding out the stream content to the temporary image the use is already seeing on the browser. However, if the user for example, uploads a new image and a new stream cotent is opened than the value of the ID changes. This is a proper solution as it ensures: (1) by having a random seed, with each new deployment you will be usind ids that are different than on the previous deployment and you survive the browser cache. (2) By hacing the client ID based Id, you can generate a unique Id number for each ID component - canonical id. You are also have in each deployment a way of deterministically knowing how ids are generated for each component, and mange the image resources created. (3) Finally, By having a map of the form CanonicalId -> ImageNrToGenerate map, you are also able to whenever needed produce a new unique image id for the stream cotent - if the user has changed the stream cotent - or re-use the old temporary image saved in the TMP folder if the user is for example refreshing. So we get the benefits of having uniqueness to by pass browser cache for images, and the advantage of having determinism for properly handling events such as page refresh or early cleanup of the TMP folder when a new image content is uploaded to replace the stream cotent that is associated to ui component whose previous stream content is now stale.
99sono
commented
9 years ago When I was using the clientId_expression to generate the id and faced the problem on the page refresh, then the following was the commit that fixed the issue.
Where the following method kind of illustrates the fix mentioned in the above post.
''' private String getCurrentUniqueId(String canonicalUniqueId) {
.format("CANONIAL%1$sUNIQUE%2$s", canonicalUniqueId, getCurrentCanonicalIdCount(canonicalUniqueId)); <----- This solutin was not good because acrross redeployments the browser cache woudl be showing me the wrong image as to what I had uploaded as the unique part was incremental across redeployment and therefore not so unique return String.format("CANONICAL%1$sINC%2$sSESSRAND%3$sEND", canonicalUniqueId,
HI,
The process by which the renderer generates a unique id on the 1.0.0 branch also leaks to tmp file leakage, where each referesh of the page will lead for a new RID to be produced for an empty file.
I've presently fixed this by doing the following.
String id = String.format("%1$s_%2$s", image.getClientId(), image.getValueExpression("value") .getExpressionString()); String rid = String.valueOf(id.hashCode());