[ https://issues.apache.org/jira/browse/MYFACES-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682560#comment-17682560 ]
Werner Punz edited comment on MYFACES-4533 at 1/31/23 3:04 PM: --------------------------------------------------------------- [https://github.com/werpu/myfaces/commit/f89a1bbdecc8e192f92de3d5de875b748c6427d9] here is the main commit for the server side: Short explanation: The class ParamsNamingContainerResolver does the heavy lifting, it basically provides a set of naming container resolution methods and wraps itself around as facade on top of the params map. Every time a key now is accessed int the params map, it checks whether a prefixed (in case of a naming container case) key is preset and if not it also checks for a normal key (which can be dropped in the future, this is just a safety fallback) The rest if the changes mostly revolved around replacing a direct paramsMap access with the access of the resolver indirection! There is some optimization potential: a) I noticed that we even in the old code had an isPostBack check which checks for a ViewState being present in the params map. The question is, is this necessary, given the FacesContext has an independent isPostBack method which does not trigger the one in the HTMLResponseStateManager b) The naming container resolution has to be done independent of UIViewRoot because it happens sometimes at stages where there is no UIViewRoot. I applied the same technique as in the client by checking for prefixes on the ViewState param. But this access is not yet puffered, again, a small optimization would be to puffer/cache it on request level, whenever possible. (we run a stream against the request params here checking for the first ViewState element being present, not good) So please check the code and comment, I will integrate fixes before starting to merge this all back down) was (Author: werpu): [https://github.com/werpu/myfaces/commit/f89a1bbdecc8e192f92de3d5de875b748c6427d9] here is the main commit for the server side: Short explanation: The class ParamsNamingContainerResolver does the heavy lifting, it basically provides a set of naming container resolution methods and wraps itself around as facade on top of the params map. Every time a key now is accessed int the params map, it checks whether a prefixed (in case of a naming container case) key is preset and if not it also checks for a normal key (which can be dropped in the future, this is just a safety fallback) The rest if the changes mostly revolved around replacing a direct paramsMap access with the access of the resolver indirection! There is some optimization potential: a) I noticed that we even in the old code had an isPostBack check which checks for a ViewState being present in the params map. The question is, is this necessary, given the FacesContext has an independent isPostBack method which does not trigger the one in the HTMLResponseStateManager b) The naming container resolution has to be done independent of UIViewRoot because it happens sometimes at stages where there is no UIViewRoot. I applied the same technique as in the client by checking for prefixes on the ViewState param. But this access is not yet puffered, again, a small optimization would be to puffer/cache it on request level, whenever possible. (we run a stream against the request params here checking for the first ViewState element being present, not good) So please check the code and comment, I will integrate fixes before starting to merge this all back down) --- Btw. also there is still one last remaining issue regarding all this in the legacy javascript codebase. I will fix this one in the upcoming days. So expect pull requests for all the branches as soon as this code has been given the ok! > TCK: Spec 790: Viewstate input element's name attribute should be prefixed > with naming container id > ----------------------------------------------------------------------------------------------------- > > Key: MYFACES-4533 > URL: https://issues.apache.org/jira/browse/MYFACES-4533 > Project: MyFaces Core > Issue Type: Bug > Affects Versions: 4.0.0-RC2 > Reporter: Volodymyr Siedlecki > Assignee: Werner Punz > Priority: Major > Attachments: image-2023-01-19-08-44-48-874.png, > image-2023-01-19-08-48-12-961.png, image-2023-01-31-10-55-59-105.png, > image-2023-01-31-13-48-30-884.png, image-2023-01-31-13-49-04-491.png, > image-2023-01-31-13-52-23-736.png, image-2023-01-31-13-53-24-862.png, > image-2023-01-31-13-54-59-301.png, namespacedView.war > > > Failing Line: > https://github.com/jakartaee/faces/blob/master/tck/faces23/namespacedView/src/test/java/ee/jakarta/tck/faces/test/javaee8/namespacedView/Spec790WithNamespacedViewIT.java#L15 > 5 > Generated Viewstate: > {code:java} > <input type="hidden" name="jakarta.faces.ViewState" > id="j_id__v_0:jakarta.faces.ViewState:1" > value="NzVhMDlkOGYwNjY1ZWZkODAwMDAwMDAy" autocomplete="off"> > {code} > The test expects the name attribute to be prefixed with `j_id__v_0`. My > understanding is this should only apply when the view root is an instance of > a NamingContainer. > The test app's faces-config has the following configuration: > https://github.com/jakartaee/faces/blob/master/tck/faces23/namespacedView/src/main/webapp/WEB-INF/faces-config.xml#L25-L28 -- This message was sent by Atlassian Jira (v8.20.10#820010)