See inline:
Nathan E Lipke wrote:
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
Why can't this other markup be returned with the body (request) in a
separate extension that holds the markup for each of the indicated
sections? Is there a reason we need the extra getMarkup calls except
when client meta data needs to be written?
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.
That is was I suspected/expected -- you write-up however doesn't
describe how this achieved -- the way things are worded now I would
expect the head request to be cached using the same cache key as the
body -- are you going to need extra "hints" like we have for resource
requests that allows the consumer to send less information and hence
get greater cacheability?
-Mike-
--
Nate
Michael Freedman wrote:
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:
[mailto:]
Sent: Thursday, October 04, 2007 11:31 AM
To:
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.
