OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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]