wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Interfaces discussion related getResource/navState
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 27 Jul 2006 08:11:33 -0400
If you are objecting to is the Portlet
not generating markup when processing a gm() request, I would ask how you
see that changing the overall requirements. I expect there to be quite
a few portlets (easily outnumbering the 'bridge' portlets envisioned in
the use case on the wiki) over the next year or so which serve their initial
markup on the first gm() response and then use gR() for fetching subsequent
markup. The issues such portlets will encounter related to page refresh
or bookmarking are no different than the use case Mike outlined.
Key points I have taken from the discussion:
1. NavState should not be altered due
to a resource URL activation to maintain consistency within the protocol.
2. A wsrp-resourceState portlet URL
parameter will be needed so that Portlets can pass state unique to the
URL.
3. Portlets will need to manage the
delta to their navState themselves using either resourceState or session
state
4. The protocol today allows the portlet
to assign an identifier within their navState for use in managing the delta
of #3, but this would require rendering the page multiple times (initial
load + once per portlet using the technique). A consumer managed ID proposal
might be more efficient, but needs work in order to arrive at a consensus.
5. Bookmarkability issues will require
at least metadata informing the Consumer that the Portlet manages such
a navState delta. It may also require a well-defined event for generating
a bookmarkable Consumer url.
Considering where we are in the overall
process, the key question we need to be addressing is what PR comments
should be generated due to our understanding and progress. I don't think
the comment needs to include the solution to #4, but perhaps multiple proposals
for solving it could be outlined (much like was done for the session property
proposal) as a means of driving toward a solution.
Rich
Subbu Allamaraju <subbu@bea.com>
07/26/2006 04:03 PM
|
To
| "wsrp >> OASIS WSRP TC"
<wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Interfaces discussion related
getResource/navState |
|
These requirements by the portlet to not use its stored
in the session
in certain cases is counter to the current spec. The current model is
that the consumer decides whether to render the portlet in its current
state, or the default state.
AFAIR, we could not come to an agreement in the past on whether the
lifecycle ID is required, and if so, the semantics around it. I doubt if
we can make progress quickly enough in the WSRP 2.0 time-frame.
Secondly, the approach that the bridge portlet is taking to render
itself asynchronously seems trouble-prone, and I doubt if such a bridge
portlet could be coded to work correctly.
I would flip the problem to the consumer side doing its aggregation
using Ajax. In that case, the bridge portlet would not be using
getResource as the primary vehicle for rendering itself. It would use
getResource just for resources, which has been the intent in the spec.
I agree that there are not enough handles to solve the problem as
stated, but we need to justify if this is the right problem to pursue.
The more we discuss about this, the less convinced I am that it is the
right problem.
Subbu
Michael Freedman wrote:
> Have updated the wiki replying to Rich's comment on how a portlet
can
> deal with maintaining navState in session. This part of the
discussion
> is what I currently see as the main sticking point to accepting the
> proposed solution that navState remain constant during getResource
> calls. As some of the discussion on the wiki is back and forth
here is
> asummary of the issue.
>
> A portlet uses getResource to either in part or as a whole render
the
> portlet. Some of these resource requests impact portlet state.
Portlet
> state (as with the proposed solution) must be maintained in a portlet
> session. The portlet wants to use this current portlet state
to render
> via subsequent getResource calls and/or subsequent getMarkup calls
(in
> the case the page is refreshed or the user interacts with another
> portlet on the page and the consumer decides to rerender everything
on
> the page). However, the portlet doesn't want to use this state
if the
> user is coming into the page (again) via a bookmark. Likewise
it
> doesn't want to use this state if the consumer policy is that page
> navigation (from/back to this page) should revert the page to its
> default/original state.
>
> The issue is how does the portlet detect whether a given getMarkup
(or
> getResource) request is in the current page lifecycle or not? We
> discussed this lifecycle issue sometime back and decided the lifecycle
> really corresponded to an action lifecycle. I.e. a new lifecycle
begins
> when an action occurs and last until either the next action or the
> consumer policy decides that a certain navigation creates a new
> lifecycle (i.e. selecting a bookmark, navigate from/to the page).
In
> the end we decided not to formailze this lifecycle in the spec because
> we felt the producer/portlet could easily manage its own notion which
> corresponded to this. However the mechanism relied on encoding
info in
> the navState. Hence the issue with getResource -- for if its
precluded
> from using navState it must either resort an obscure and maybe not
even
> valid manipulation via client side javascript (Rich's suggestion).
The
> issues for me are:
> 1) Is there a technical solution so the portlet can implement its
own
> notion of lifecycle?
> 2) If there is, how obscure/feasible is it?
> 3) What would the spec need to do to directly support a notion of
> lifecycle and what burden would this place on the consumer?
> 4) Which is better (2) or (3)?
>
> As for what we could do in the spec, I wonder if we can get away with
> asking the consumer to send an actionLifecyleId in all requests and
> define a reserved value to mean the initial/default lifecycle.
> -Mike-
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
_______________________________________________________________________
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.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]