[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
Good point. I keep getting questions on why names are different, also making one wonder if the semantics are actually the same or not. Subbu 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. > > > > _______________________________________________________________________ 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]