wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-comment] JSR286's MULTI-PHASE render not supported in WSRP 2.0
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Wed, 26 Sep 2007 14:37:41 -0400
Yet another option ...
6. Define an extension to MarkupContext
to carry <head> info
- pros:
* Does not move around
location of existing items - fallbacks to current spec when not supported
* Does not involve additional
network roundtrips
- cons:
* ??
Rich
| Nathan E Lipke <nlipke@bea.com>
09/14/2007 12:22 PM
|
|
To
| wsrp-comment@lists.oasis-open.org
|
|
cc
|
|
|
Subject
| [wsrp-comment] JSR286's MULTI-PHASE
render not supported in WSRP 2.0 |
|
Recent drafts of JSR-286 have included the concept
of multi-phase
render. This allows a portlet to populate headers (including cookies)
and add elements to the <head> (such as script, style and meta elements)
section of the surrounding page.
WSRP 2.0 currently does not support this. There are a number of ways we
can support this:
1. Like JSR-286 defines
1. Portlet Descriptsion [O] boolean isMultPhaseRenderSupported
2. MimeRequest [O] QName renderPhase
* wsrp:head
* wsrp:body
* Requires structural changes to spec
late in the spec
* Allows full independent caching of
head an body separately
2. As discussed on the call: make the producer call the 286 portlet
twice and make the consumer cache head info
1. Consumer calls getMarkup on the portlet
before rendering its
headers and <head> section
2. The producer calls the 286 portlet twice
1. for HEAD
2. for BODY
3. The getMarkupResponse contains both the
<head> and <body>
sections as well as any headers
4. The consumer sets the headers, renders
the head and caches
the body
5. The consumer later renders the body
* Requires no WSRP spec changes (although
some notes would be
helpful)
* Need to bend the no <head>/<body>
tag rule
* Requires the consumer to cache markup
* Does not allow independent caching
of head and body
3. As discussed with Stefan: Send a WSRP defined event
1. The consumer sends a wsrp:getHead event
2. The response MUST contain a updateResponse
with
markupContext populated
3. The consumer MUST interpret this as the
head content and NOT
the normal content
* Requires little spec change
* Requiring markup as a response to
an event seems odd (as
compared to the rest of the spec),
same for special
interpretation on the consumer
* Allows full independent caching of
head an body separately
4. Add a well known resource name (e.g. wsrp:head)
1. The consumer calls getResource() during
head render phase
which returns head and headers
* This would require advertisement of
the head section
(similar to solution #1)
* Allows full independent caching of
head an body separately
5. Do nothing/use vendor dependent extensions
For what its worth: BEA Weblogic Portal already supports multi-phase
render as an extension called getRenderDependencies(). This has worked
fairly well for us so far. However we would prefer to interoperate with
3rd party consumers and producers.
Thanks,
Nate
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely
for the use of the individual or entity named in this message. If you are
not the intended recipient, and have received this message in error, please
immediately return this by email and then delete it.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]