[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
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 <subbu@bea.com> > 04/18/07 12:12 PM cc > wsrp <wsrp@lists.oasis-open.org> > 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]