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

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

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?
>-----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
>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
>Also MimeResponse should not return the portletContext rather it should be
>the ResourceResponse.
>agreed. see comment above
>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
>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?
>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]