Re: [wsrp] Navigational parameter restrictions

[Richard Jacob <richard.jacob@de.ibm.com>]

I don't think that navigationalParams should be used to solve the "request
property" problem.
It is pulbic navigational state that has a different lifetime. And I think
we should leave this that way.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             03/22/06 08:48 PM         Stefan Hepper                       
                                       <sthepper@hursley.ibm.com>          
                                                                        cc 
                                       wsrp <wsrp@lists.oasis-open.org>    
                                                                   Subject 
                                       Re: [wsrp] Navigational parameter   
                                       restrictions                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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