Ganesh schrieb:
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
Well I have been sending a commend regarding the eval/ upate etc... to
the comments mailing list I hope it will be read (my last mail regarding
auto eval obviously again was read by that /dev/null guy since I did not
get any answer).
My personal guess is lets wait if we get a response before doing further
discussions. I have somewhat mixed feelings about it as well.
But the question also arises do we really break compatbility on protocol
level, I dont think so, but we clearly break it on component level, but
only if it is used, so I´d rather have this extension being implemented
on both implementations before going alone in this regard.
I am not very eager to allow component authors behavior which works on
myfaces alone on this level, but on the other hand I think the
implementation is clearly broken and makes life miserable for the
components authors if we dont cover this corner case.
