[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] GetResource, NavState, and events
I disagree with the assesment that Rich's writeup is more chatty.
Your proposal seems to enforce a new event being fired on each
"transientNavState" change.
Also what really strikes me is the comparison of navStates. Wouldn't his
mean that the Consumer would be forced to keep all the portletss navState
in the session in order to being able to tell whether the "old" invoked
navState is different to the "new" one? If this is the case this really is
a no-go for me.
Besides that I found the definition very difficult to understand and to be
honest am not sure yet about all the consequences this imposes.
Also I found it problematic that the events should be invoked even if the
portlet is not targeted. In this case the consumer might not even have
navState for all portlets and thus might not be able to tell if "old" and
"new" navState are different.
Rich's writeup instead leaves the "updateNavState" event only to one case:
the user intends to bookmark the page.
Also the "removeDeltas" is only set if the Consumer thinks it is
appropriate to. It is not sent every navState change as an addition. Rather
it is sent when the user e.g. changes to a new page and the consumer
chooses to reset to the default navState in that case (some consumers might
not..)
So I guess your proposal and Rich's proposal are not really targetting at
the same use case and are not really solving the same thing.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Michael Freedman
<michael.freedman
@oracle.com> To
wsrp <wsrp@lists.oasis-open.org>
08/17/06 12:13 AM cc
Subject
Re: [wsrp] GetResource, NavState,
and events
Well, I think we are just arguing over details ... both schemes seem based
on the same premise with your being generic and hence more chatty while
mine is targeted and hence more efficient.
I.e. wsrp:removeNavigationalContextDelta vs. wsrp:newUserInteractionSet.
Aren't these really the same in that they indicate a context change has
occurred and that any producer managed transient state related to the
navigationalContext should be released/not used? Maybe a good name for the
event is: wsrp:releaseTransientNavigationalContext. The main difference is
the frequency this is sent. My proposal only sends this event if the
portlet (in getResource) has indicated it has transientNavigationalContext.
Your proposal assumes that a portlet subscribing to such an event is always
behaving this way and needs notification.
as for wsrp:updateNavigationalContext vs. your
wsrp:updateNavigationalContext aren't we again defining the same thing? It
seems both a meant to allow the consumer to give the producer an
opportunity to reexpress/update its navContext with the distinction once
again that in my case the consumer is informed under what circumstances
this might be interesting.
Is one of the reasons you went down the path you did because you really
want this to apply to the getMarkup case as well? If so why? If not, why
wouldn't we prefer a solution that limits processing these events?
-Mike-
Rich Thompson wrote:
My suggestion was meant to be quite a bit simpler than this,
something along the lines of:
wsrp:newUserInteractionSet: This is a Consumer generated event which
informs the Portlet that Consumer policy has determined that a new
set of End-User interactions are starting (e.g. the nature of how the
End-User has navigated is causing the Consumer to reset any
transiently managed navigational state). The Consumer SHOULD treat
Portlets which handle this event as managing a portion of their
navigationalState internally and Portlets which indicate they handle
this event MUST reset any internally managed extension to
navigationalState upon receipt of this event. As a signal, this event
carries no payload, but for extensibility does use an open content
model.
wsrp:updateNavigationalContext: This is a Consumer generated event
which informs the Portlet that the Consumer is building a URL which
the End-User MAY store for later activation (e.g. as a bookmark).
Upon receiving this event, Portlets SHOULD update and return a
NavigationalContext to the Consumer which enables later activation of
the URL to cause the Portlet to generate markup closely approximating
what is currently being generated for the End-User. As a signal, this
event carries no payload, but for extensibility does use an open
content model.
The simplicity of this approach arises from the Consumer always
treating Portlets which handle these events as having dirty navState
(outside of immediately after sending one of these events).
Effectively the two available operations the Consumer can trigger are
resetting and flushing into navState the Portlet managed extension of
navState.
Rich
Michael Freedman
<michael.freedman@oracle.com>
To
08/15/2006 07:34 PM wsrp
<wsrp@lists.oasis-open.
org>
cc
Subject
[wsrp] GetResource,
NavState, and events
It was suggested last week that we consider using a predefined
consumer
event to manage resyncing navigational state that can't be propagated
in
a getResource response. I was tasked with fleshing out a proposal
based
on this. I think something like this could work -- does anyone like
this better then the lifecycle/bookmark id proposal?:
define a new response field in the resource response called:
[O] boolean navigationalContextDirty;
navigationalContextDirty: this boolean flag indicates whether this
getResource operation resulted in the portlet making a delta to its
navigationalContext that should become reflected in the
navigationalContext before processing the next client request (that
relies on the current navigationalContext). The default is false.
wsrp:updateNavigationalContext:
This is a consumer generated event sent to all portlets that returned
a
navigationalContextDirty flag equal to true on a prior getResource
operation. This event must be sent only if the opaque portion of the
NavigationalContext in the current request is identical to the opaque
portion of the NavigationalContext of the client getResource request
that resulted in the navigationalContextDirty flag being set to true.
If the states aren't identical then the
wsrp:removeNavigationalContextDelta event is sent instead. In either
case the end result is to remove the consumer notion that the context
is
dirty. This event will only be sent on the next client request that
would result in either a PBI, HE, GM invocation meeting the above
requirements (even if such request isn't directly targeted at this
portlet).
wsrp:removeNavigationalContextDelta
This consumer generated event is sent to all portlets that returned a
navigationalContextDirty flag equal to true on a prior getResource
operation. This event must be sent only if the opaque portion of the
NavigationalContext in the current request is not identical to the
opaque portion of the NavigationalContext of the client getResource
request that resulted in the navigationalContextDirty flag being set
to
true. (Otherwise the wsrp:updateNavigationalContext event is sent).
After sending the event the consumer notion that the context is dirty
is
removed. This event will only be sent on the next client request
that
would result in either a PBI, HE, GM invocation meeting the above
requirements (even if such request isn't directly targeted at this
portlet).
FYI ... another aspect of this issue which we haven't yet discussed
is
the behavior of the public portion of the navigationalContext when it
changes as a result of a getResource. Right now because we are
leaning
to a resoluttion that prevents this from changing in a getResource
any
ajax logic that relies on getResource can't be coordinated with other
portlets on the page. Until we can satisfy ourselves that JSF, .NET,
and other like view technologies that will have native components
which
use Ajax can without mods to their code run in Subbu's in protocol
mechanism I fear this restriction will be too extreme. For example
Ajax
code that is invoked when one selects a customer id (to drill/expand
customer info within the portlet view) couldn't be propogated to
other
portlets. For 2.0 I would be willing to exclude this use case as
long
as we realize we likely will need to rework getResource if we find
that
the above view technologies aren't seemlessly adapted to our in
protocol
mechanism.
-Mike-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]