Re: [wsrp] NavState vs. Interaction State or what is the purposeof interaction state?

[Subbu Allamaraju <subbu@bea.com>]

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

I should have added, "unless you treat the nav state as an explicit 
input to each action, and that it is different from what is returned 
from a pbia". I find it cleaner/simpler to return and encode the same 
value for navState. But I agree that it is an implementation choice.

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

The developer may not care about these differences directly, but it is 
much cleaner (for a producer container) to differentiate between the 
input for an action and an input for a render.

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

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