[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 purposeof 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]