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 10:53:22 -0400
The navState would be the navigational
state of the Portlet and resourceState would be any additional state required
to properly render the requested resource, especially if the resource is
dynamically generated.
Rich
Stefan Hepper <sthepper@hursley.ibm.com>
05/31/06 10:50 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] NavState vs. Interaction
State or what is the purpose of interaction state? |
|
Subbu Allamaraju wrote:
>> 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.
>
> I agree.
>
> Subbu
I don't quite follow, given that it is a get resource that does not
modify state, why would we need these additional resourceState?
Stefan
>
>
>> *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
>>
>>
>> ---------------------------------------------------------------------
>> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]