Ok I just got an answer from Roger Kitain regarding this issue and he
basically agrees with my stance, but he also says that all this must be
a little bit more properly specified in the long term, so he requests a
list of all ajax related issues which we have faced so far.
Ganes, Alex please add to the list.
So far I can remember following issues:
a) The Response Writer behavior, the component authors cannot properly
trigger other inserts, updates attributes or evals, in a ppr response
because the response writer already has opened an update command.
Solution defer the added startUpdates... etc.. until the update is
closed (stack other commands), Sideefects deferring of eval and other
scripts, but is implementable within the bounds of the spec and does not
break anything.
example:
<changes>
<update id="...">
<eval >
</eval>
</update>
</changes>
becomes
<changes>
<update id="...">
</update>
<eval >
</eval>
</changes>
breaking it apart in the middle is no viable way because the scripts
themselves might interrupt half open elements and update does not work
anymore as expected.
<changes>
<update id="...">
<eval >
</eval>
</update>
</changes>
becomes
<changes>
<update id="...">
</update>
<eval >
</eval>
<update id="...">
</update>
</changes>
Cannot work out as expected because you get two updates on the same
root id doing both only half the work!
b) properly defined handling of embedded script and style blocks, either
started via startElement, or by directly writing them out.
Only solution without sideeffects so far found, client side parsing.
If split on the server script the rendering order of script blocks and
html blocks is taken out of the hand of the component author, which
might cause rendering issues.
Myfaces so far has solved this by adding auto eval for embedded scripts
and script src blocks wherever needed, and currently auto eval
of embedded styles is discussed!
example:
<update>
...
component.startElement("script
...
</update>
renders to
<update ..>
...
<script type="text/javascript>
</update>
to enable full legacy component set compatibility for the ppr case
something has to walk over the page and manually eval the script
blocks in browsers which do not do auto evals.
We added exactly this behavior so that embedded scripts are properly
executed.
c) There is currently no direct way to handle script=src in an eval
block you however resolve that on code level by adding your own
source loading code (this is not fixable within the bounds of JSF2
probably should be added for 2.1 as attribute)
d) The RI has a broken behavior regarding the parsing of the body or
head tags in the update cycle javax.faces.ViewRoot, javax.faces.Head and
javax.faces.Body, they split the code via regular expressions which
ultimately fails in following cases
comments emitting the tags
javascripts embedding the tags in strings
and styles embedding those tags in strings
attributes changes on the RIs side within the body tags are ignored for now
Myfaces has solved this so far by adding a minimal ll parsing instead of
following the regular expression route, attributes changing as well works.
e) Generally the current specification cannot deal with fileuploads
this is deferred for now because fileupload handling will be added in
the next servlet spec. Myfaces has added nothing yet, but the modular
infrastructure is prepared so that we can add other transports in the
long run (iframe is needed as transport for now to enable this)
f) General control of the xhr request queue size, there are usecases
where an unlimited request queue size is unwanted. The current
specificaton enforces an unlimited request queue size.
(not solvable within the current specification probably has to be
resolved within 2.1)
Before sending all this in, have I missed anything in this area?
Werner
Bruno Aranda schrieb:
Being naive and not understanding the details of this issue, I want
just to comment on breaking compatibility. I think that at this
particular moment is not that bad if what we get is a better
implementation, because this is what users want. If you say that it
makes life easier for component developers this should be a good
change, and creating new components was never the best thing in the
previous versions. Is it breaking the spec? Or an
implementation/interpretation of the spec issue? If it is the latter,
there are good chances that mojarra will be updated as well, no? And
if the spec is not clear, it should be fixed.
Keep up the good work,
Bruno
2009/7/13 Werner Punz <[email protected]>:
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.
