[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Navigational parameter restrictions
strings would be fine. I suggested scalars so consumers can do some type checking as well. -Mike- Subbu Allamaraju wrote: > I agree. > > Could you elaborate on why you wanted this to be restricted to be > scalar types and not just strings? > > Subbu > > Michael Freedman wrote: > >> Well, you have me smiling somewhat. I raised, we discussed, and we >> decided to take no action on helping producers to manage request >> scoped data within a wsrp (action) lifecycle. We decided that the >> producer can handle this without further support from us. I believe >> this to be true though note that improvements could be made by >> formalizing the multi-window on a portlet instance case, and >> potentially an outOfScope event case. Anyway, >> NavigationalParameters are not (and should not be) designed to >> address this problem. NavigationalParameters are public navigational >> state. Navigational state is managed at a different lifecycle then a >> wsrp (action) lifecycle. >> -Mike- >> >> Subbu Allamaraju wrote: >> >>> I agree with the theme, but a problem in JSR286 is that portlets >>> can't pass on objects from action to render. >>> >>> One example is the spring integration issues you posted to the >>> JSR286 EG (pardon me folks on this list). Similar needs come up with >>> most bridge portlets. While these issues are specific to JSR286, the >>> issues may be relevant to general purpose producers as well. >>> >>> I'm not favoring one way or the other, but there are certainly some >>> real-world use cases to consider. >>> >>> Subbu >>> >>> Stefan Hepper wrote: >>> >>>> I would be also in favor of this approach. It would make the >>>> alignment with JSR 286 simpler as in the JSR 286 we only support >>>> Strings as navigational parameters. >>>> >>>> Stefan >>>> >>>> Michael Freedman wrote: >>>> >>>>> Should we restrict the returned navgiationalParameters in >>>>> UpdateResponse to only be values representing xml scalar types >>>>> [int, string, etc.]? The issue here is similar to the one that >>>>> caused us to restrict what the producer can encode in the URLs it >>>>> writes into markup, namely many consumers will prefer to manage >>>>> these values in the same way they manage navigational state. As >>>>> this is commonly handled by writing the state into every URL in >>>>> the page, shouldn't we make it easy for a consumer to do so? If >>>>> so, should we back track all together and only support scalar >>>>> types? Or do we preserve the full open model for those properties >>>>> that aren't set by producers and might presumably either be >>>>> computed by the consumer vs. being encoded? >>>>> -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 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]