OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Groups - Interfaces concall added


If you think a more generic solution is needed with regards to sections, how does the following sound?
  • Change the MultiPhaseRender from boolean to a list of Strings
  • The consumer MUST call getMarkup() for each phase as enumerated
    • Unless the consumer has this phase validly cached
    • The consumer SHOULD call the phases in order (but cannot be guaranteed)
    • The portlet MAY decide each phases' cacheability
    • The response MUST contain the phase (sent in MarkupParams) as an extension to MarkupContext, to ensure the extension was understood by the producer
  • The spec should define well known strings for wsrp-extra:head and wsrp-extra:body

We have found the HEAD section is often more cacheable than the portlet content.
Our most common use case is as follows:
  • The portlet relies on a common set of static (rewriting possible) styles and/or scripts in the <head> tag
    • These are cached initially (thus getMarkup("head") is only called once per session)
  • The portlet then uses the scripts/styles on many pages (states)
    • getMarkup("body") may be called many times
This limits the amount of traffic (and processing) to a minimum.
However, the producer is free not follow this by setting the "head" to be non-cacheable.

--
Nate

Michael Freedman wrote:
470BB3C2.90704@oracle.com" type="cite"> My preference is to separate the issue of rendering client response meta data (headers) from outputing markup in the client response that is distinct from the location of the portlets markup in that response.  And while I think that the header solution requires/will rely on this two phase rendering I don't think the rendering of other markup must/should.  And finally on the rendering of markup for other sections I would prefer a more generic solution that accounts for writing into another other well known or nameable section -- i.e. though head is the common/likely example why limit ourselves to this vs. providing a more generic solution?

As for caching, have you found in practice that the content for the head section truly is tied to the current state of the portlet and hence should be cached at the same level as the portlet markup?  Or is this just a convenience for the implementation?
   -Mike-

Nathan Lipke wrote:

Attached please find a draft of our proposal to add support Head section (and headers) markup.

 

Our goals included:

·         Compatibility with JSR 286

·         Independent caching of the head and body sections

·         Support for most (all) markup languages

·         Reuse of existing WSRP types and methods

 

Thanks,

 

Nate

 

-----Original Message-----
From: Michael.Freedman@oracle.com [mailto:Michael.Freedman@oracle.com]
Sent: Thursday, October 04, 2007 11:31 AM
To: wsrp-interfaces@lists.oasis-open.org
Subject: [wsrp-interfaces] Groups - Interfaces concall added

 

 

Interfaces concall has been added by Mr Michael Freedman

 

Date:  Thursday, 11 October 2007

Time:  08:00am - 09:00am PT

 

Event Description:

1-888-967-2253 or +44 118 924 9000 (Europe)

meeting ID: 345337

passcode: 060606

 

Agenda:

Discuss extension proposal for carrying portlet markup in a getmarkupresponse that is intended for other locations in the consumers markup response.  I.e. return markup for the Head section.

 

Minutes:

 

 

View event details:

http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=16808

 

PLEASE NOTE:  If the above link does not work for you, your email

application may be breaking the link into two pieces.  You may be able to

copy and paste the entire link address into the address field of your web

browser.

 


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.

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]