[jsr-314-open] Partial Response writer in conjunction with the component API

[Dan Allen]

>From the jsr-314-comments mailbox comes this message from Werner Punz
concerning the partial response writer and nested eval blocks.

(For future reference, the moderator of the 314-comments mailbox, which is
currently me, will forward approved messages using the introduction above).

---------- Forwarded message ----------
From: Werner Punz <werner.punz at gmail.com>
Date: Mon, Jul 13, 2009 at 4:40 AM
Subject: [jsr-314-open] Partial Response writer in conjunction with the component API
To: jsr-314-comments at jcp.org


Hello everyone I have a comment regarding the partial response writer in
conjunction with the component API.
Since this is a grey area I am not quite sure if it is possible to add that
behavior or not.

Following, currently the partial response is handled via a partial response
writer and a special lifecycle, so far so good and very clear.
But the issues arise if you want to combine it with the component api.

Here is the problem:

Usually the partial lifecycle automatically opens an update on the partial
response before working on the component tree or single components to be
rendered!
This is needed to gain backwards compatibility and still enable ppr on
legacy components, however there is an issue with this approach!

What if a component wants to render scripts explicitely or style changes.
MyFaces has covered the script part so far with an optimized auto eval on
the
updated dom tree, but wouldnt it be nice to allow eval blocks from the
component level as well, after all we have the api, and so far it only
really can be utilized
outside of jsf in this manner!

Lets have a detailed look:

Component has to be rendered under a PPR context:
the cycle opens an update with startUpdate and the id of the root component
to be updated!

The lifecycle then calls the encodeBegin on the parent component and that
one traverses into its sub components.

What happens now is that those subcomponents use startElement etc... to
render the html styles and scripts, they do not really
have a safe way to break out and add their own eval sections etc... although
the API is in place
(the only unsafe way would be to close implicitely the update section add
the eval section and reopening again by
parsing again the ppr data from the request and try to avoid any sideeffects
into the lifecycle, this way would not
be broken by my proposal)

What I would recommend as default behaviour, and this can be added since it
is not really specified anyway as far as I could see.
Allow the opening of other sections within an open section and render them
after the main section is closed (stacking embedded sections
and defer the rendering of them).

Example
startUpdate ....
   startEval ....
   endEval

..
endUpdate

would result in a
<update> ..
</update>
<eval>
</eval>

block


This behavior would give new components which then can check for being in a
ppr cycle a better rendering
behavior by being able to control their ppr behavior directly. It also would
not break compatibility to the
existing implementations, and probably as well would be within the scope of
the existing spec.


Kind regards

Werner Punz
Apache MyFaces
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090714/037a40b0/attachment.html