[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Public review comment: NavState semantics with respect togetResource
I agree, I think it should be encodeable state particular to that resource. The main problem/misunderstanding in my opinion is introduced by the reuse of markupParams and markupResponse. Perhaps we should really have distinct params&response types here and stuff only in, what is really needed (see our famous validNewModes discussion). 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 Michael Freedman <michael.freedman @oracle.com> To wsrp <wsrp@lists.oasis-open.org> 06/14/06 07:30 PM cc Subject [wsrp] Public review comment: NavState semantics with respect to getResource The semantics of how consumers manage navigationalState with respect to getResource aren't clearly specified. What is it we intend? The question is do we intend the consumer to treat getResource navState like getMarkup navState or differently? With getMarkup, the navState encoded in the renderURL becomes the new navigational state for the portlet when the renderURL is invoked. Does the same thing happen for a getResource or does the consumer treat this NavState as something that is particular to the getResource call but unrelated to the general portlet context? I.e. the consumer retained navState for this portlet remains as whatever it currently was prior to this getResource call? If the first case is true then navState is an inappropriate place to encode resource specific state as this would become part of the overall portlets navigational state. In this case where would one encode such resource specific state? Should we add a new token resourceState much like interactionState on actionURLs? Or should we recommend that this information merely be encoded in the resourceId the resource writes into the resource URL? -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]