and in addition to that I would propose to also state that the new
semantics of performing state changes should only be used when not
accessing the resource serving via a HTTP GET.
Stefan
Richard Jacob wrote:
> one more I forgot at the F2F:
>
> now that getResource has idempotent and state changing semantics, shouldn't
> we allign that with the JSR and rename getResource() to serveResource().
> The getResource() may confuse people indicating a different semantics.
>
> 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
>
>
>
> Richard
> Jacob/Germany/IBM
> @IBMDE To
> Subbu Allamaraju <>
> 04/18/07 12:12 PM 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
> <>
> To
> 04/17/07 05:28 PM wsrp <>
> 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.
>
>
>
>
>
>
>
