wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] NavState vs. Interaction State or what is the purpose ofinteraction state?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 31 May 2006 07:28:52 -0400
I recall a discussion about sending
interactionState to getResource as well as navState as it can have either
post or get style semantics. The outcome of that discussion was that between
navState and resourceID, Portlets had a lot of flexibility already. Looking
at this again from a consistency point of view, I can see adding a resourceState
field and accompanying portlet url parameter.
Rich
Subbu Allamaraju <subbu@bea.com>
05/30/06 06:51 PM
|
To
| Michael Freedman <michael.freedman@oracle.com>
|
cc
| wsrp <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] NavState vs. Interaction
State or what is the purpose of interaction state? |
|
I raised a question about getResource not taking additional
input (like
a resourceState as you suggest) sometime last year. The outcome of the
discussion was that that producer is responsible for generating
resourceID to point to the state. IMO, that is not the cleanest solution
since it would require the producer to manage the mapping somewhere, or
encode it in the navigationalState. But the later option seems
inconsistent given the semantic difference between resources and markup.
But that's what we have now.
Subbu
Michael Freedman wrote:
> What is the significant benefit you see to distinguishing between
them
> relative to building the url? Also, if you believe it is significant
> and the significance is tied to the model you define, why doesn't
> getResource take a resourceState field to carry additional state needed
> to process getting the resource?
> -Mike-
>
> Rich Thompson wrote:
>>
>> The model in the protocol is that navState is what is required
to
>> properly render the portlet for the user. Interaction state provides
>> any additional state needed to process the action.
>>
>> My analogy to the web world distinguishes between state sent on
the
>> post and what is passed on a redirect to a get request. Often
the
>> state on the post is a superset of what is on the get request.
Outside
>> of the serialize/deserialize issues of getting these on and off
urls,
>> I don't see why a web app would distinguish between them internally.
>> On the other hand, I do see significant benefits to distinguish
them
>> relative to building the url and hence also within the WSRP protocol.
>>
>> Rich
>>
>>
>> *Michael Freedman <michael.freedman@oracle.com>*
>>
>> 05/30/06 04:38 PM
>>
>>
>> To
>>
Subbu Allamaraju <subbu@bea.com>
>> cc
>>
wsrp <wsrp@lists.oasis-open.org>
>> Subject
>>
Re: [wsrp] NavState vs. Interaction State or what is the
purpose of
>> interaction state?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> See comments inline:
>>
>> Subbu Allamaraju wrote:
>>
>> > My interpretation is that nav state represents outcome of
action
>> > processing, where as interaction state is usually an input
to the
>> > action. It is not managed by the consumer beyond the current
request.
>> >
>> > [MF] Your (first sentence) definition matches what I saw
as the
>> > original intent before MarkupParams was passed to the PBI.
I don't
>> > really understand your second (sentence) point: navState
must be
>> > explicitly output from a PBI for the consumer to continue
to maintain
>> > it hance from a technical perspective there is now difference
as to
>> > whether the inputs to PBI were interactionState or navState
-- the
>> > operation still has to decide what values constitute the
new navState
>> > and respond.
>> >
>> > Another key (and probably more important) difference is that
>> > interaction state could be different between two URLs generated
by a
>> > portlet, but both URLs will most likely carry the same nav
state. In
>> > this case, I can't think of a way of mapping interaction
state as
>> > navigational state.
>> >
>> > [MF] Again, from a PBI point of view NavState is (now) both
input and
>> > output, in addition navState can change during the interaction
>> > processing, this is a superset of what interaction state
does -- in
>> > the end the developer is merely encoding state into the ActionUrl
--
>> > hence it shouldn't be problemmatic to encode both PBI only
state +
>> > PBI/render state into navState. Are you thinking that
many developers
>> > end up modeling navState in explicit objects and hence anything
that
>> > isn't needed to represent render state would need to come
from a
>> > different abstraction? If so, how common is this in
a web developer
>> > world where such state are usually seen as request parameters
that are
>> > then pushed into models/backing (managed) beans?
>> >
>> > Subbu
>> >
>> > Michael Freedman wrote:
>> >
>> >> Given the current state of the spec, I am trying to figure
out what
>> >> the purpose of interactionState is. Can anyone
help? My
>> >> recollection is that originally interactionState was
the PBI
>> >> equivalent of navigationalState (for getMarkup) prior
to us adding
>> >> the "performance enhacement" that passed PBI
MarkupParams so
>> >> action/render response could occur in a single request.
This no
>> >> longer seems to be our intent as shown by the URL samples
in section
>> >> 10.2.1.9. I.e. the second example expresses an
actionURL with both
>> >> navigationalState and interactionState. What is
the new model? I
>> >> can think of something like interactionState holds those
values that
>> >> augment the action processing while navigationalState
holds those
>> >> values that augment the rendering process -- but that
seems pretty
>> >> meaningless given that in most applications state is
state that you
>> >> compute with and render from. I.e. why wouldn't
developers merely
>> >> represent all such state as NavigationalState (particularly
because
>> >> this form now has an opaque and non-opaque portion)?
Since navState
>> >> doesn't inherently carry forward at the end of an action/event,
you
>> >> must explicitly set it it seems to offer everything interactionState
>> >> does but in one object that spans all operations.
>> >> -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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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]