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:26:52 -0400
You are right in that this requires
the client render the page multiple times (the initial page load + once
per such portlet), clearly a non-desirable side-effect.
The currently available solution simply
returns a script block which directly does the desired reload (i.e. no
function definitions, just in-line script). This script could use any of
the available URL activation techniques ... the keys are: the URL is in
the markup (i.e. rewriting works) and that it executes on page load. A
more advanced technique could use AJAX to grab the reloaded page and then
just extract the portlet's markup and the new URL to use for updating the
current page, but that could get quite sofisticated ...
Rich
Michael Freedman <michael.freedman@oracle.com>
07/26/2006 01:21 PM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
cc
| wsrp@lists.oasis-open.org
|
Subject
| Re: [wsrp] Interfaces discussion related
getResource/navState |
|
Inline questions...
Rich Thompson wrote:
I inserted some replies to your comments on the wiki page, but here is
my summary:
1. It certainly is technically valid and feasible for a portlet to do the
encoding, but the solution is not obvious and providing guidance in the
area (as well as the rest of the AJAX-oriented domain) will make a big
difference.
I am sure it is but I clearly don't get it based on the
limited javascript knowledge I have. Can you be more explicit? Your
scheme seems to rely on the fact that a renderURL sets the current navState
for the portlet -- i.e. by having the client double render the page (first
with no navState and second with the navState the portlet encoded in the
renderURL) the new navState is established. Or is do you have something
else in mind? Can you describe in gernal terms the solution?
2. The solution might be
simpler with the actionLifecycleID proposal, but guidance would still be
needed. I suspect such an idea would have other uses as well. We should
explore how feasible it is across the full range of interesting Consumer
designs and whether bookmarks and forward/back navigation would create
confusion.
Rich
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]