You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2009/05/06 19:02:21 UTC
Re: h:head and h:body in JSF 2.0 + javax.faces.ViewState in the response
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
>>>
>>
>>
>
>
Re: JSF 2.0 + javax.faces.ViewState
Posted by Werner Punz <we...@gmail.com>.
Ok Roger thanks for the clarification on this issue.
I also did not have portlets in my mind when I was asking
myself why this had been changed!
Obviously the Es in the EG are more E than I am an E,
so ashes to my head ;-)
That also makes things a slightly bit faster because you do not have
to walk over all forms doing the field update!
Werner
Ganesh schrieb:
> Hi Roger,
>
> I'm impressed - the "E" in "EG" obviously makes sense. Yes, it's true,
> portlets must be considered.
>
> If someone bothers to use a multi form approach within a servlet
> container and he wants to update the viewstates of other forms he may
> well explicitly elect them for rerendering.
>
> Best Regards,
> Ganesh
>
> Roger Kitain schrieb:
>> Hi Ganesh,
>>
>> I met with the Ajax EG team members about this and we decided to go
>> the route of updating
>> the submitting form, because in a portlet environment, each form may
>> have its own view/viewstate
>> that is different - in which case we would clobber that. Impls must
>> update the submitting form (at least),
>> and we lieave it (for now) as an impl detail if they want to update
>> all forms with
>> javax.faces.ViewState (since that is not specified). We have not
>> handled all portlet related cases
>> in the spec - that I am sure of.. I think if need be we can address
>> this in an MR.
>>
>> -roger
>> Ganesh wrote:
>>> Hi Roger,
>>>
>>> With the last minute changes I think an error has leaked in. It now
>>> states that the javax.faces.ViewState is only to be replaced within
>>> the submitting form. Imho all forms viewstates absolutely need to be
>>> replaced.
>>>
>>> Below I'm citing the new spec jsdoc text on this subject for the rest
>>> of the list to understand what we are about.
>>>
>>> Best regards,
>>> Ganesh
>>>
>>> * If an update element is found in the response with the
>>> identifier javax.faces.ViewState:
>>>
>>> <update id="javax.faces.ViewState">
>>> <![CDATA[...]]>
>>> </update>
>>>
>>> locate and update the submitting form's javax.faces.ViewState
>>> value with the CDATA contents from the response.
>>>
>>
>
Re: JSF 2.0 + javax.faces.ViewState
Posted by Ganesh <ga...@j4fry.org>.
Hi Roger,
I'm impressed - the "E" in "EG" obviously makes sense. Yes, it's true,
portlets must be considered.
If someone bothers to use a multi form approach within a servlet
container and he wants to update the viewstates of other forms he may
well explicitly elect them for rerendering.
Best Regards,
Ganesh
Roger Kitain schrieb:
> Hi Ganesh,
>
> I met with the Ajax EG team members about this and we decided to go
> the route of updating
> the submitting form, because in a portlet environment, each form may
> have its own view/viewstate
> that is different - in which case we would clobber that. Impls must
> update the submitting form (at least),
> and we lieave it (for now) as an impl detail if they want to update
> all forms with
> javax.faces.ViewState (since that is not specified). We have not
> handled all portlet related cases
> in the spec - that I am sure of.. I think if need be we can address
> this in an MR.
>
> -roger
> Ganesh wrote:
>> Hi Roger,
>>
>> With the last minute changes I think an error has leaked in. It now
>> states that the javax.faces.ViewState is only to be replaced within
>> the submitting form. Imho all forms viewstates absolutely need to be
>> replaced.
>>
>> Below I'm citing the new spec jsdoc text on this subject for the rest
>> of the list to understand what we are about.
>>
>> Best regards,
>> Ganesh
>>
>> * If an update element is found in the response with the
>> identifier javax.faces.ViewState:
>>
>> <update id="javax.faces.ViewState">
>> <![CDATA[...]]>
>> </update>
>>
>> locate and update the submitting form's javax.faces.ViewState
>> value with the CDATA contents from the response.
>>
>
Re: JSF 2.0 + javax.faces.ViewState
Posted by Roger Kitain <Ro...@Sun.COM>.
Hi Ganesh,
I met with the Ajax EG team members about this and we decided to go the
route of updating
the submitting form, because in a portlet environment, each form may
have its own view/viewstate
that is different - in which case we would clobber that. Impls must
update the submitting form (at least),
and we lieave it (for now) as an impl detail if they want to update all
forms with
javax.faces.ViewState (since that is not specified). We have not
handled all portlet related cases
in the spec - that I am sure of.. I think if need be we can address
this in an MR.
-roger
Ganesh wrote:
> Hi Roger,
>
> With the last minute changes I think an error has leaked in. It now
> states that the javax.faces.ViewState is only to be replaced within
> the submitting form. Imho all forms viewstates absolutely need to be
> replaced.
>
> Below I'm citing the new spec jsdoc text on this subject for the rest
> of the list to understand what we are about.
>
> Best regards,
> Ganesh
>
> * If an update element is found in the response with the identifier
> javax.faces.ViewState:
>
> <update id="javax.faces.ViewState">
> <![CDATA[...]]>
> </update>
>
> locate and update the submitting form's javax.faces.ViewState
> value with the CDATA contents from the response.
>
JSF 2.0 + javax.faces.ViewState
Posted by Ganesh <ga...@j4fry.org>.
Hi Roger,
With the last minute changes I think an error has leaked in. It now
states that the javax.faces.ViewState is only to be replaced within the
submitting form. Imho all forms viewstates absolutely need to be replaced.
Below I'm citing the new spec jsdoc text on this subject for the rest of
the list to understand what we are about.
Best regards,
Ganesh
* If an update element is found in the response with the identifier
javax.faces.ViewState:
<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>
locate and update the submitting form's javax.faces.ViewState
value with the CDATA contents from the response.
Re: h:head and h:body in JSF 2.0 + javax.faces.ViewState in the
response
Posted by Simon Lessard <si...@gmail.com>.
Not sure on my side, I'm really not into AJAX. I followed the discussions,
but really not deeply enough to get that kind of detail. :(
~ Simon
On Wed, May 6, 2009 at 1: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?
>
>
> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: h:head and h:body in JSF 2.0 + javax.faces.ViewState in the
response
Posted by 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