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
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
|