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] Comments on the schema/spec changes from last week



To the original points ...

1. The use case discussed at the F2F was Consumers who could support receiving various levels of state update in the ResourceResponse. I do agree with Richard that we went too far when adding the statechange flag to RuntimeContext, it more properly belongs in ResourceParams with the corresponding PortletContext in ResourceResponse rather than MimeResponse. For Consumers not supporting any state update, the flag should be set to "readOnly".

2. Duplication eliminated if we move the fields as recommended in #1.

3. I noticed the spec and wsdl were out of sync on the placement of the events element and fixed it.

Rich



Michael Freedman <michael.freedman@oracle.com>

04/18/2007 05:30 PM

To
"'wsrp'" <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Comments on the schema/spec changes from last week





It doesn't handle the situation when the consumer gets the initial
content from the portlet.
   -Mike-

Mike Caffyn wrote:

>I have to say something as there seems to be a lot of duplication here.
>getResource is now the doALL. Are pbia() and gm() required anymore? :-) Is
>there anything that getResource doesn't handle apart from eventing?
>
>Mike
>
>-----Original Message-----
>From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
>Sent: Wednesday, April 18, 2007 6:12 AM
>To: Subbu Allamaraju
>Cc: wsrp
>Subject: Re: [wsrp] Comments on the schema/spec changes from last week
>
>1.
>I agree. We must not allow portlet clones to appear on gM().
>Therefore the statechange flag should not be moved to runtime context (it's
>also more complicated for a mapping layer since the location between v1 &
>v2 changed totally) and it should be passed to getResource() in
>ResourceParams.
>Also MimeResponse should not return the portletContext rather it should be
>the ResourceResponse.
>
>2.
>agreed. see comment above
>
>3.
>I do not see any reason either.
>
>Some more comments:
>Portlet managed modes are described using ItemDescription which has a
>localized description and a non-localized name.
>This is similar to custom mode description, however I think the situation
>is different here.
>Custom modes were kind of negotiated between the Consumer and the Producer
>and therefor the Consumer was able to render the decoration accordingly.
>However with portlet managed modes we expect the consumer to display the
>mode text in the decoration according to what the portlet specified.
>
>I think having just the non-localized name attribute is not sufficient,
>since the modes could have names like
>"urn:com.your.company:somebrand:bla:bla:mode".
>This is certainly not what should be displayed in the UI.
>Therefore I think that portlet managed modes should also have a localized
>display title.
>
>Mit freundlichen Gruessen / best regards,
>
>        Richard Jacob
>______________________________________________________
>IBM Lab Boeblingen, Germany
>Dept. 2289, WebSphere Portal Server Development 1
>WSRP Team Lead
>WSRP Architecture & Standardization
>Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
>
>IBM Deutschland Entwicklung GmbH
>Vorsitzender des Aufsichtsrats: Johann Weihen
>Geschäftsführung: Herbert Kircher
>Sitz der Gesellschaft: Böblingen
>Registergericht: Amtsgericht Stuttgart, HRB 243294
>
>
>                                                                          
>             Subbu Allamaraju                                              
>             <subbu@bea.com>                                              
>                                                                        To
>             04/17/07 05:28 PM         wsrp <wsrp@lists.oasis-open.org>    
>                                                                        cc
>                                                                          
>                                                                   Subject
>                                       [wsrp] Comments on the schema/spec  
>                                       changes from last week              
>                                                                          
>                                                                          
>                                                                          
>                                                                          
>                                                                          
>                                                                          
>
>
>
>
>
>1. My understanding of the use case brought up for state changes during
>markup/resource request was to let the consumer/producer allow state
>changes provided such a change does not require the producer to
>implicitly clone the portlet and return new portletContext.
>
>But the schema changes now allow state changes to happen regardless of
>cloning. In the updated schema, the producer can return portletContext
>with markup/resource responses. What is the use case for this?
>
>2. On pbia and handleEvents, portletStateChangeRequired flag is
>duplicated. Since RuntimeContext is always present, we don't
>portletStateChangeRequired elements in InteractionParams and EventParams.
>
>3. On a related note, the position of the "events" element was changed
>in UpdateResponse. Any reason for this change?
>
>Subbu
>_______________________________________________________________________
>Notice:  This email message, together with any attachments, may contain
>information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>entities,  that may be confidential,  proprietary,  copyrighted  and/or
>legally privileged, and is intended solely for the use of the individual
>or entity named in this message. If you are not the intended recipient,
>and have received this message in error, please immediately return this
>by email and then delete it.
>
>
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]