[
https://issues.apache.org/jira/browse/MYFACES-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679058#comment-17679058
]
Werner Punz edited comment on MYFACES-4533 at 1/20/23 9:04 AM:
---------------------------------------------------------------
Thanks for the analysis, yes the postback is slightly different, the
specification is quite unclear on this, in one section of the jsdoc it talks
about sending the raw jakarta.faces.ViewState always and in a later section
talks about having to prefix every parameter you send down in the
namingContainer case.
I thought to have sent the prefixed one and the non prefixed one for now.
— reedit
I have double checked the spec on execute, seems like you were right, this is a
bug in my JSF_TS codebase:
Here is the section from the jsdoc:
*Otherwise, there are specific identifiers that need to be sent. Create the
post data argument with the name jakarta.faces.partial.execute and the value as
a space delimited string of client identifiers.*
*If options.execute does not exist, create the post data argument with the name
jakarta.faces.partial.execute and the value as the identifier of the element
that caused this request.*
So this means the execute on the button in this case very likely has to go
(although again the jsdoc is unprecise here because it does not really tell you
that).
I will also double check with Mojarras request for this test to get this
absolutely right, because the spec leaves it in its wording a little bit open
whether you should send it or not! But I assume leaving it out is correct. But
doing it was a wrong understanding, remembering on my side during the
reimplementation!
—
was (Author: werpu):
Thanks for the analysis, yes the postback is slightly different, the
specification is quite unclear on this, in one section of the jsdoc it talks
about sending the raw jakarta.faces.ViewState always and in a later section
talks about having to prefix every parameter you send down in the
namingContainer case.
I thought to have sent the prefixed one and the non prefixed one for now.
The best bet here is to follow Mojarras lead and check what they do in this
case.
as for the execute, having sent the button id additionally is correct, because
execute always has to include the originating element. (But I have to double
check the jsdoc for that, I remember it being there)
> 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, 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)
