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

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(a)gmail.com&gt; 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(a)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