Re: h:head and h:body in JSF 2.0 + javax.faces.ViewState in the response

[Matthias Wessendorf <ma...@apache.org>]

On Wed, May 6, 2009 at 7:02 PM, Werner Punz <we...@gmail.com> wrote:
> 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?

Martin ? :)

-Matthias
>
>
> 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
>>>>
>>>
>>>
>>
>>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf