[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] sematics of overlapping QNames for navParams?
Thanks Rich, that clarifies a lot. Can we add as clarification in 6.1.12 that the name in the NameString must reference to the identifier? About my second point: So basically you are saying that a wiring happens between different identifiers and not that reference to a common shared data. So it is more like the event model than a data sharing model. Can we also clarify this, as I think also other people would think that this is meant to be a data sharing model, like I did? Stefan Rich Thompson wrote: > > Inserted inline with <rt> ... > > Rich > > > *Subbu Allamaraju <subbu@bea.com>* > > 09/18/2006 02:26 PM > > > To > Stefan Hepper <sthepper@hursley.ibm.com> > cc > WSRP TC <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] sematics of overlapping QNames for navParams? > > > > > > > > > > I assume it is too late to restrict this to one QName instead of a QName > > That's what the errata is for :) > > <rt>The Qnames are definitions of the semantics of items which can be > mapped into this navParam. The navParam is defined by the identifier > field.</rt> > > > Here a few scenarios: > > > > portlet 1: > > nav param aaa:p1, bbb:blub <rt>identifier = "1"</rt> > > nav param aaa:p2 <rt>identifier = "2"</rt> > > > > portlet 2: > > nav param bbb:blub, ccc:bla <rt>identifier = "3"</rt> > > > > portlet 3: > > nav param ccc:bla, aaa:p2 <rt>identifier = "4"</rt> > > > > > > questions: > > > > 1. what if portlet 1 creates an url setting bbb:bulb to "123"? Will it > > get the param under the name aaa:p1 or under bbb:blub? I didn't find > > anything in the spec about this. I expected to find that the portlet > > must only use the first entry in the QName list. > > Yes. My interpretation is that the portlet should be ready to receive > the value against any of the names it declared. > > <rt>/The portlet receives the value against the identifier it has > declared./</rt> > > > 2. What is the happens when portlet 1 sets > > aaa:p1 = "111" ? > > <rt>Translate this to setting identifier 1 to a value of "111".</rt> > > > Can portlet 2 receive this as new value bbb:blub? (I assume yes based on > > the current spec) > > No. My interpretation is the the recipient has to declare the aliases. > Since it did not declare "aaa:p1", it will not receive it. > > <rt>Portlet 2 would recieve identifier 3 with the value "111".</rt> > > > Can portlet 3 receive it as new value for ccc:bla? (unclear to me from > > the current spec, it states: "SHOULD supply the same value to Portlets > > which provide a navigationalParameterDescription referencing the same > > QName in the names array", and ccc:bla is not on the QName list of > > portlet 1) > > No, per the same argument. > > <rt>Portlet 3 would recieve identifier 4 with the value "111".</rt> > > > > > Can portlet 1 receive it as new value for aaa:p2? > > No > > <rt>Only if Portlet 3 returns identifier 4 with the value "111".</rt> > > > 3. What happens if portlet 2 sets > > bbb:blub = "222" ? > > > > Can portlet 1 receive this as new value for aaa:p1 and portlet 3 as new > > values for ccc:bla? I assume yes. > > Portlet 1 will receive this as new value for bbb:blub and portlet 3 will > not receive it. > > The reason we ended up having multiple names was to account for alias > names. Alias are meant to help the consumer decide whether to send the > param (or dispatch an event) to a given portlet. If one of the names > matches, it will dispatch it, otherwise not. > > There is no name translation in this process. That is, the recipient > will receive it under the same name as was sent/set by the sender. > > <rt>We made a distinction between identifying a navParam and the QNames > to which it should be mapped. The runtime messages use the NamedString > type, but it appears we were not explicit that the identifier field is > what would appear in the name field of this type and that the QNames are > just for the purpose of mapping navParams across portlets.</rt> > > > Subbu > >>Register now for BEA World 2006 --- See http://www.bea.com/beaworld<< > _______________________________________________________________________ > 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]