[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] navigational state change
Richard, Do agree that if The portlet alway receives the navState it encoded itself and nothing else. From the protocol point of view it is perfectly valid. which I was not sure that is the case for the consumer impl I was referring to. Thanks, Wesley Richard Jacob wrote: >Why do you think it is questionable? >The portlet alway receives the navState it encoded itself and nothing else. >From the protocol point of view it is perfectly valid. >It's merely the Consumer's choice using rewriting to augment the URLs with >additional information to enable a better user experience, i.e. make back >button, bookmarks and reloads work properly. > >Mit freundlichen Gruessen / best regards, > > Richard Jacob >______________________________________________________ >IBM Lab Boeblingen, Germany >Dept.8288, WebSphere Portal Server Development >WSRP Technical Lead >WSRP Standardization >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >Email: mailto:richard.jacob@de.ibm.com > > > > Wesley > Budziwojski > <Wesley.Budziwojs To > ki@Sun.COM> Michael Freedman > Sent by: <michael.freedman@oracle.com> > Wesley.Budziwojsk cc > i@Sun.COM OASIS WSRP TC > <wsrp@lists.oasis-open.org> > Subject > 04/27/06 01:20 AM Re: [wsrp] navigational state > change > > > > > > > > > > >Mike, > >Thanks for the use case. >If I am not mistaken some Consumer implementations choose to encode >navig state for all interested portlets thus >making this scenario work ok but perhaps adherence to the spec somewhat >questionable? > >Wesley > >Michael Freedman wrote: > > > >>reload() works as expected as it merely resubmits the URL that >>contains the encoded navigational state. Things "break" however when >>you have two portlets on a page each representing new navigational >>state in render URLs. If the user selects one and then the other URL, >>the rendition of the first reverts to its previous navigational state >>as the new state is not encoded in the second portlets URL. >> -Mike- >> >>Wesley Budziwojski wrote: >> >> >> >>>Subbu, >>> >>>"In that sense, the portlet is not changing its state directly." >>> >>>One would think that direct or indirect change is a change :) >>>Interesting; Direct change - meaning Consumer changed navig state and >>>sent it in markupParam) or >>>indirect change -only Producer is aware of the change (new state) and >>>renders based on that? >>> >>>What does following render() and reload expected to do? >>> >>>Thanks, >>>Wesley >>> >>> >>>Subbu Allamaraju wrote: >>> >>> >>> >>>>In this case, the portlet is not returning new navState, but is >>>>encoding this state in a URL. This is navState change, but happens >>>>when a UA submits the request to the consumer. In that sense, the >>>>portlet is not changing its state directly. >>>> >>>>Also not that this example is true only for render URLs. >>>> >>>>Subbu >>>> >>>>Wesley Budziwojski wrote: >>>> >>>> >>>> >>>>>Section 3.12 >>>>> >>>>>"Examples of when one of the optional steps >>>>>(performBlockingInteraction and handleEvents) might not be used >>>>>include: >>>>> >>>>> * The End-User interacting with a URL that simply looks to render >>>>> the Portlet's markup with a different navigational state (e.g. >>>>> with the next set of results from a search). In this case, >>>>>both of >>>>> the first two steps could be skipped. " >>>>> >>>>>It seems that to render Portlet's mark-up with a different >>>>>navigational state implies that Portlet needs to change its >>>>>navigational state and >>>>>if so the change of the Portlet's state should happen in PBI or >>>>>there is no navigational state change in this use case? >>>>> >>>>>Thanks, >>>>>Wesley >>>>> >>>>> >>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>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 >>> >>> >> >>--------------------------------------------------------------------- >>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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]