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

[Dan Allen]

Seems reasonable to me, but I haven't been deeply involved in the PPR area
of the spec, so I may be overlooking a potential downside.

On Tue, Jul 14, 2009 at 7:43 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

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


-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090714/914ab740/attachment.html