Ok Since Ganesh pointed it out, this is even better.
We probably wont need a parser at all.
The section describing javax.faces.ViewRoot as
ppr update id basically omits the entire parsing stage.
They way I interpete it for now is that we can
serve the innerHTML of the html tag and have
a simple innerHTML replacement (with optional
script triggers, for embedded scripts, which also
can be covered by a following eval part)
So this means the work is entirely offloaded
to the responseWriter.
I have committed my parser, but I am more than glad
to rip it out again and drop it into oblivion
(I am always a big fan of throwing away code to reduce
the codesize)
Another issue:
The spec seems to have changed regarding the viewState handling on the
client side in the pr
pr case last minute: It seems that it now is just changing the viewState
of the submitting form of the ppr request. Is this correct or an errata
in the latest spec?
If yes do we still have to add missing viewState elements if the form
does not have one, and is the entire, change all viewstate elements part
entirely dropped?
The last jira entries did not show any big changes except for
s/identifier/name which we requested?
Can anyone of the EG guys comment on this?
Werner
Werner Punz schrieb:
Looks ok to me, the parsing is not omitted but instead
the option to render the head and body without parsing is added.
Either way, I have the parser in place now and will commit it tomorrow.
So we have the harder part in place and working and it is fast enoguh.
80.000 characters are handled within 1.5 seconds which is fast enough!
I will commit it tomorrow since I am currently at a customer...
Werner
Roger Kitain schrieb:
Ganesh wrote:
[2] The jsdoc on javax.faces.response defines a behaviour for update
elements with the id javax.faces.ViewRoot. By testing with the RI I
found out that this behaviour is triggered if an AJAX requests triggers
a naviagtion rule that leads to a different page. It's a cool thing to
have a well defined behaviour in this case, but the spec doesn't define
it. It's just what Mojarra does. Can you please add a paragraph that
defines the circumstances under which the server has to respond with
javax.faces.ViewRoot?
This is now fixed - see:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=554
[3] In the javax.faces.ViewRoot case Mojarra returns a complete document
with DOCTYPE, html, head and body. It is left to the Javascript
implementation to separate these and replace the head and body sections.
This is a tedious task involving a parser that deals with html comments,
Javascript comments and CDATA sections within the HTML page. The
Javascript code Mojarra brings for this is unsufficient and fails for
many cases. We are currently working on a parser. Things would be a lot
easier if the spec would force the server to return separate CDATA
blocks within javax.faces.ViewRoot for the head and the body tag and to
omit the html tag and the DOCROOT. This can't be too hard to implement,
because head and body are rendered by h:head and h:body. Can you
please define the format for javax.faces.ViewRoot to contain 2 CDATA
sections, 1 optional with the head tag and 1 required with the body tag?
Fixed- See:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=557
Best Regards,
Ganesh Jung
