[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Re: [wsrp-comment] JSR286's MULTI-PHASE render not supported inWSRP 2.0
I think in this timeframe option 6, i.e. have an extension seems the best
thing to me.
For now we should be fine with the extension to MarkupContext allowing
portlets/producers to write to the head section.
The reason for this is that currently we need buffering on the respone
anyway due to the nature of WS stacks, therefor I would refrain for now
from having a seperate roundtrip.
Once we feel that having an additional roundtrip and WS-stacks support
streaming we can define a better solution.
So the solution for me would be close to Nathan's 2.
Consumer calls gM() once.
Producer dispatches to portlet twice (in the case of JSR286) and gathers
head and markup fragement section. Head stored in extension.
JSR286 WSRP Proxies first deliver head section (JSR286 render head call),
cache the markup, and on the second call deliver the markup fragment.
However, I do think that we should also have an extension to the
PortletDescription saysing whether a porlet is intending to write to the
head or not (similar to JSR286 DD metadata).
The reason for this is that JSR286 Consumer implementations would like to
avoid the container call render twice (retrieve head and body) when it is
not necessary.
Without that flag Consumers must invoke wsrp proxy portlets always twice in
the render phase which is a performance hit I would like to avoid.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------|
|Rich Thompson <richt2@us.ibm.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------|
|wsrp@lists.oasis-open.org |
>------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------|
|09/26/2007 08:38 PM |
>------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------|
|[wsrp] Re: [wsrp-comment] JSR286's MULTI-PHASE render not supported in WSRP 2.0 |
>------------------------------------------------------------------------------------------------------------------------------------------------|
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>
To
09/14/2007 12:22 PM 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]