Re: [wsrp] Interfaces discussion related getResource/navState

[Rich Thompson <richt2@us.ibm.com>]

This is not related to the definition
of gR(), the discussion just uses this as a shorthand for activating a
resource url. Resources being either std binary or markup oriented is the
thing causing this thread of discussion.

Rich

Subbu Allamaraju <subbu@bea.com>

07/27/2006 10:44 AM

To	Michael Freedman <michael.freedman@oracle.com>
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] Interfaces discussion related getResource/navState

Mike,

We can only speculate if getResource would be "the" preferred
solution 
in the near term. It depends on on how well/fast we come up with better
solution(s).

The big disconnect I see is that getResource was designed to be a 
semantic equivalent of WSRP 1.0 style resource serving with the added 
benefit of supplying portlet's context and current state. Extending the
scope of this beyond this does not fit very well in the overall 
protocol, as the current thread proves.

Subbu


Michael Freedman wrote:
> That's what I thought, hence I still consider it an unacceptable 
> solution for the problem.  What I think we need to do know is
decide 
> whether the situation I describe is unique to a very small set of
> peculiar uses or more common the world where portlets use Ajax and
> getresource together.  You and I both seem to think the later
while 
> Subbu still sees the former.  If we think its reasonably common
I don't 
> think its appropriate to close the issue related to getResource and
> navState because I believe the decision we would be choosing is only
> partially complete and prevent too many portlets from operating correctly.
>      -Mike-
> 
> Rich Thompson wrote:
>>
>> 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
>>
>> *Michael Freedman **_<michael.freedman@oracle.com>_* 
>> <mailto:michael.freedman@oracle.com>
>>
>> 07/25/2006 01:17 PM
>>
>>                
 
>> To
>>                
 "wsrp >> OASIS WSRP TC" _<wsrp@lists.oasis-open.org>_
>> <mailto:wsrp@lists.oasis-open.org>
>> cc
>>                
 
>> Subject
>>                
 [wsrp] Interfaces discussion related getResource/navState
>>
>>
>>
>>
>>                
 
>>
>>
>>
>>
>>
>>
>> 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