Hi,
My problem with the attributes and eval sections of the xhr response (as
well as with insert and delete) is that the JSR-314 specs jsdocs define
them, but Mojarra 2.0 doesn't use them. Mojarra 2.0 sends an
eval/attributes/insert/delete/extensions xhr response under *no*
circumstances. Also the main spec PDF document doesn't mention them at
all. If you read the PDF, you'd think, only the updates section of the
xhr response is relevant. Also, Mojarras implemetation of
eval/attributes/insert/delete is rudimentary. I frequently wondered why
they defined this at all.
Do we want to have identical xml data exchange in MyFaces 2.0 xhr as in
Mojarra 2.0? Will the users rely on the XML data format? The spec only
defines the syntax of the XMLSchema, so we are spec compliant, even if
we send the scripts and styles via the eval or extensions (or other)
sections. On the other hand I was trying to maintain Mojarra
compatibility on the transport layer and until now and I'm using the
MyFaces script togther with Mojarra 2.0 successfully. Please comment on
this: Do we want 100% compatibility on the xhr transport layer between
Mojarra 2.0 and MyFaces 2.0 or do we want to enhance transport beyond
Mojarra along the lines the specs draw?
If we decide for the second (enhance transport):
Why would you put <script>...</script> inside the attributes section?
The spec says it is used to >>update the DOM element attribute value
(whose name matches attribute name), with attribute value<<. I can't see
in which way this is connected to replacing scripts.
Best regards,
Ganesh
Werner Punz schrieb:
Ganesh schrieb:
Hi,
We fiddled quite a bit with auto eval of embedded and external
scripts, because IE and Safari don't execute them when they come in
with xhr.
Now, here's the same problem for styles. The following example with
display red text in FF+Safari, but black text in IE. Do you think, we
should add auto style eval for JSF 2.0 xhr requests?
Yes definitely, if it is possible, which I do not know ;-)....
But in the end I think this should be resolved via the attributes
section of the ppr response, which again leads me to the question no
one answered a while ago regarding the response writer, if we should
add the capability to allow eval or attribute sections within update
sections (which are then deferred until the update is closed ;-) ),
which would enable exactly this (as well as proper eval blocks from
the component api)
