Re: [wsrp] Navigational parameter restrictions

[Subbu Allamaraju <subbu@bea.com>]

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