Details
-
Bug
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
2.0.1-core
-
None
-
None
-
WebSphere Application Server 8.5 64bit on Windows 7, with MyFaces 2.0 support, trinidad-api-2.0.1.jar, trinidad-impl-2.0.1.jar, Internet Explorer 9, Quirks mode.
The problem can be seen in Production or Development stage.
Description
On the JSF page we defined
xmlns:trh="http://myfaces.apache.org/trinidad/html"
The page includes the following part:
<trh:script partialTriggers="amountByClient " text="...some script here..."/>
when partialTriggers occures I can see in the network monitor the following comes back to the browser:
<?xml version="1.0"?>
<partial-response>
<changes>
<!-- some data here -->
<!-- this is the data for my trh:script component - the ID matches with that on the IE HTML page ->
<update id="j_id1850516215_5d7c425d">
<![CDATA[]]>
</update>
<eval>
<![CDATA[...some script here - the same, as defined in the trh:script text attribute...]]>
</eval>
</changes>
</partial-response>
So, I believe what JavaScript on the page is trying to do is replace the script with id
j_id1850516215_5d7c425d with empty string (that's not very good indeed, but shouldn't harm).
Then it would "call" the part in <eval> tag. That's would be great - this is what we need.
However, while the partial-response XML is processed it finaly comes to javax-faces/jsf.js, function outerHTML, which:
1. checks if the final markup is not empty/null -> which in fact is: see update element above.
(actually it checks !markup, which evaluates to true if markup is empty string).
2. If it is null, it throws an exception, so no other processing is performed. Especially the eval part.
3. What's strange, if you check the outerHTML function code, if it passes step 1, it then replaces the original markup, but if and only if the final markup is not empty string.
So I believe step 1 above is not really required, as it doesn't harm the method itself.
Or maybe we should check if markup is not null, instead of !markup?
We are just migrating from JSF 1.2 and can't finalize the migration because of this error.
The scenario works correctly with the same JSF page on the older environment (JSF 1.2, trinidad 1.2), but reagarding partial submit I believe it is completely different story then.
Best Regards,
Maciej
