[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
To keep consistent behavior, it is safe to either replace with current values or empty strings when there is no transition request. I agree with Richard's use case. Allowing the consumer to pick any mode/state could lead to inconsistent user experience. Regards, Subbu Richard Jacob said the following on 11/11/2003 06:43 AM: >Ok, this is a different semantic here - other then the "no-change" semantic >we discussed before. >I think the intent of our and JSR168 semantic is that if there is no mode >parameter on the URL then the portal (or consumer) will (or should) remain >in the same mode as it was (that's different to the "don't care" >semantics). >We say in 10.2.1.4 "Activating this URL includes a request to CHANGE the >mode parameter in MarkupParams into the mode specified [...]". >So one could interpret (although we are not explicit) the absence of mode >(or the non-replacement to stay in the template scope) is a request to stay >in the same mode. > >We need to be carefull here, otherwise we might observe different >behaviours for different producer-consumer pairs. >One use case: >Portlet has multiple pages for edit mode linked via navigational links >(prev, next, etc.). >The portlet does not place mode parameter in the navigational URLs. >User changes the portlets mode to "edit", via decoration. -> >markupParams.mode=edit >User clicks on next in edit mode (without specifying mode=wsrp:edit in the >link), now when the consumer may choose what to do, it could change to view >mode -> markupParams.mode=view. >This would prevent the user from ever getting to the next page. >This would enforce the portlet programmer to *always* code the mode >parameter in URLs (which is not the case either in the JSR168 spec nor in >our spec). > >And in this case this leads us back to the discussion whether we should >enforce the producer to *always* replace these {wsrp-...} tokens in >templates :-) >Therefor I would say that the semantic for not having these params in the >URL means "no change" rather then "don't care" (if we choose to do the >non-replacement processing). > >Mit freundlichen Gruessen / best regards, > > Richard Jacob >______________________________________________________ >IBM Lab Boeblingen, Germany >Dept.8288, WebSphere Portal Server Development >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >Email: mailto:richard.jacob@de.ibm.com > > >|---------+----------------------------> >| | Andre Kramer | >| | <andre.kramer@eu.| >| | citrix.com> | >| | | >| | 11/11/2003 09:46 | >| | AM | >|---------+----------------------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > | | > | To: wsrp-interop@lists.oasis-open.org | > | cc: | > | Subject: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > >Richard, > > >On the "always transition" option you raise, I supposed it would be useful >for a portlet to say "I don't care about the mode / window state" on a URL. >When we introduce events we may be able to make use of this extra semantic >information. For 1.0, a link with "mode=wsrp:help&windowState >={wsrp:windowState}" allows the portal to select the best window state for >displaying help but "mode=wsrp:help&windowState=wsrp:normal" would >constrain the portal to call the portlet in the normal window state just >because that was the current mode when the url was rendered. > > >regards, >Andre > > >-----Original Message----- >From: Richard Jacob [mailto:richard.jacob@de.ibm.com] >Sent: 10 November 2003 18:05 >To: Andre Kramer >Cc: wsrp-interop@lists.oasis-open.org >Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] >foll ow-up: templates > > > > > > >my comments in <rj> > > >Mit freundlichen Gruessen / best regards, > > > Richard Jacob >______________________________________________________ >IBM Lab Boeblingen, Germany >Dept.8288, WebSphere Portal Server Development >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >Email: mailto:richard.jacob@de.ibm.com > > > > > >|---------+----------------------------> >| | Andre Kramer | >| | <andre.kramer@eu.| >| | citrix.com> | >| | | >| | 11/10/2003 05:49 | >| | PM | >|---------+----------------------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > | >| > > > | To: wsrp-interop@lists.oasis-open.org >| > > > | cc: >| > > > | Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: >[wsrp-interop] foll ow-up: templates >| > > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > > >(e) was just for catching tokens allowed by the grammar but not really >expected in templates, <ak> below. ><rj> agreed >Rich: is wsrp-Token not also a relict that should be removed from the spec? > ></rj> > > > > > >-----Original Message----- >From: Richard Jacob [mailto:richard.jacob@de.ibm.com] >Sent: 10 November 2003 15:11 >To: Andre Kramer >Cc: wsrp-interop@lists.oasis-open.org >Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] >foll ow-up: templates > > > > > > > > > >Good analysis. >I agree to a, b, c - at the bottom line it comes to "replace them", since >b) is opaque one could consider no substitution as being indeed a >substitution, i.e. the consumer would pass {wsrp...} back to the producer, >the producer needs to handle it in that case. >{wsrp-secureUrl} should be categorized as c) not as e). > > > > > ><ak>I don't {wsrp-secureUrl} is sensible for templates as we have both >secure and normal versions for constructing urls.</ak> > > > > > ><rj> agreed, I missed the fact that even for default templates we have a >secure one :-), given that I would say it fits in e) as you say it </rj> > > > > > >Since we defined a default value (false) one could even argue that a >no-change falls back to default. >However I would prefer to replace here anyways. > > > > > >On d): >Leaving {wsrp-...} seems the most appropriate here unless we have a special > > >wsrp-value for that (e.g. "wsrp:null"). >It seems more natural to indicate a no-change to me. >This would make {wsrp-...} reserved tokens in the spec. (perhaps we should >do that for any wsrp defined string anyway in 1.1). > > > > > ><ak> we did use the "wsrp-" to mean our URI and "{" is used in matching so >we are on pretty safe ground here.</ak> > > > > > ><rj> agreed </rj> > > > > > >I think the argument that a mode or window state might carry {wsrp-..} on >purpose is not strong enough. In the spec we encourage (although not >enforce) people to namespace their self-defined values so my expectation on > > >clashes is very low here. > > > > > ><ak>custom modes & window states need to be declared in service/portlet >descriptions which also helps.</ak> > > > > > ><rj> agreed </rj> > > > > > >On e): >what is {wsrp-token} for again? Didn't we miss to remove it once we dropped > > >the namespace URL thing? >This leaves it at {wsrp-fragmentID} being the only one left in e). >Here I would handle it as d), no substitution means "not set". > > > > > ><ak>{wsrp-token} is unneeded and {wsrp-fragmentID} seems currently >underspecified.</ak> > > > > > >What strikes me a little bit is the fact that we introduce a more >complicated semantic in this processing, people might get confused. >It would be easier to understand if we said: >Required tokens on an URL must be replaced with values as well as all >portlet URL params (10.2.2.9). >All optional tokens don't need to be substituted (or better: have our >"wsrp:null" for that) and fall back to default. > > > > > >One additional point: If we introduce d) don't we contradict our >conformance statements in 10.2.1.4 and 10.2.1.5 where we say that >modes/window states MUST be either the wsrp-defined ones or custom ones >supported by the producer? So a "MUST replace" here perhaps would fit >better? (btw. what makes it complicated for the producer to replace the >{wsrp-mode} with the current mode value the portlet is in? This would mean >for templates: staying in the same mode is a transition from mode x to mode > > >x.) > > > > > ><ak>I would go for "MUST be either the wsrp-defined ones or custom ones >supported by the producer IF replaced". Here the "wsrp-defined" is an >unfortunate use of "wsrp-". </ak> > > > > > ><rj> ok, so here you go for the option modes/states do not need to be >replaced, right? What about my question for always to transition even if it > >is mode x -> mode x ?</rj> > > > > > >With that argument it would put a) b) c) d) into one equal group: "MUST >replace". >Then we would only have e) with "leave-as-is" which is little bit >underspecified (as Andre said). >This seems even an easier semantics to me. > > > > > >Mit freundlichen Gruessen / best regards, > > > > > > Richard Jacob >______________________________________________________ >IBM Lab Boeblingen, Germany >Dept.8288, WebSphere Portal Server Development >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >Email: mailto:richard.jacob@de.ibm.com > > > > > > > > >|---------+----------------------------> >| | Andre Kramer | >| | <andre.kramer@eu.| >| | citrix.com> | >| | | >| | 11/10/2003 10:40 | >| | AM | >|---------+----------------------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > | >| > > > > > > | To: wsrp-interop@lists.oasis-open.org >| > > > > > > | cc: >| > > > > > > | Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: >[wsrp-interop] foll ow-up: templates >| > > > > > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > > > > > >Agree, there are multiple cases here: > > > > > >a) tokens spec says must be replaced (10.2.2.9). These should always be >substituted and so should never occur in a query string. [My original query > > >was aimed at making {wsrp-urlType} one of these but only for default >templates.] > > > > > >b) tokens that are opaque to the consumer. Producer can use whatever it >likes here (including doing no substitution). > > > > > >c) tokens that are booleans. "true" or "false" must be substituted. > > > > > >d) token that control mode and window state transitions. > > > > > >e) {wsrp-fragmentID}, {secureURL} and {wsrp-token} (!) > > > > > >{wsrp-urlType} (a) >{wsrp-url} (a) >{wsrp-portletHandle} (a) >{wsrp-userContextKey} (a) >{wsrp-portletInstanceKey} (a) >{wsrp-sessionID} (a) >{wsrp-navigationalState} (b) >{wsrp-interactionState} (b) >{wsrp-requiresRewrite} (c) >{wsrp-mode} (d) >{wsrp-windowState} (d) >{wsrp-secureURL} (e) >{wsrp-fragmentID} (e) >{wsrp-token} (e) > > > > > >Only (d) and (e) are likely to cause (very minor) problems so we should not > > >impact the other types. > > > > > >My preference would be to only clarify that (d) can use {wsrp-mode} and >{wsrp-windowState} or "" to signal no change is requested. We can introduce > > >a "null" token (in our namespace) in next version. > > > > > >(e) is underspecified but allowed by our grammar (10.2.3). Seems safer not >to substitute anything for these. > > > > > >regards, >Andre > -----Original Message----- > From: Rich Thompson [mailto:richt2@us.ibm.com] > Sent: 07 November 2003 18:22 > To: wsrp-interop@lists.oasis-open.org > Subject: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] > follow-up: templates > > > > > > > > > I think there are a couple of issues here. First, I think it is > worthwhile having a value with a semantic meaning that no change in > mode or windowState is being requested as this eliminates processing > cycles for the Consumer. What that value should be is an interesting > question. > > > > > > The argument in favor of "" is that no mode or windowState will ever > carry this name and therefore it is a 'safe' value. > The argument in favor of {wsrp-mode} (or ...) is that it makes the > querystring (presuming that is where it is in the URL) more readable. > > > > > > > > > I think Producers will need a bit of logic that supplies the values > for whatever the Portlet does not set. If a Producer chooses to > simply leave tokens like {wsrp-interactionState} in the URL, then the > > > Consumer is required to supply that as the interactionState during > the performBlockingInteraction invocation (and likewise for > navigationalState). The simplest bit of logic for the Producer would > be to initialize a set of variables to "" and then provide an > interface which allows the portlet to set any of them it wants. When > the URL's string value is being placed into the markup, the Producer > can simply walk the template and blindly replace the portlet URL > parameters with their values. While this may make odd looking > querystrings, I would note they would be valid (and commonly occur > today). > > > > > > Rich > > > > > > > Andre Kramer > <andre.kramer@eu.citrix.com> > > > To > 11/07/2003 12:14 PM wsrp-interop@lists.oasis > -open.org > cc > wsrp-conformance@lists.o > asis-open.org > Subject > [wsrp-conformance] RE: > [wsrp-interop] > follow-up: templates > > > > > > > > > > > > > > > > > > > Yes, I favour 3 as it works for unexpected as well as expected {} > token. Query strings such as ?a=x&b=&c=z look strange so "" does not > seem a natural choice. > > > > > > > > > Also, custom modes & window states are constrained by the values > negotiated and nav and interaction state are opaque to the consumer. > > > > > > > > > regards, > Andre > > > > > > > > > -----Original Message----- > From: Richard Jacob [mailto:richard.jacob@de.ibm.com] > Sent: 07 November 2003 16:25 > To: wsrp-interop@lists.oasis-open.org > Cc: wsrp-conformance@lists.oasis-open.org > Subject: [wsrp-interop] follow-up: templates > > > > > > > > > I wanted to add a question on the topic discussed yesterday on both > calls > about token replacement found in templates (sorry for crossposting): > Does the producer/portlet need to replace all tokens in a template > when > generating URLs? > I think we said yes but might replace them with empty strings. > What in the case of {wsrp-mode} or {wsrp-windowState}? For example a > render > template like: http://bla.com/here?mode={wsrp-mode}&ws > ={wsrp-windowState}.... > > > > > > > > > I see the follwing options here: > 1. producer replaces with the mode it wants to "change" to (might be > the > current mode), could be one of the valid wsrp-modes or a custom-mode > 2. producer replaces with "" (blank), like suggested in yesterdays > call. > In this case we have an interpretation-issue on the consumer side > when > processing these URLs. > Does a "" mode name mean a mode name containing of an empty string? > In this > case the conumer might not know this mode (abviously) and map it to > view. > Or does a "" mode mean, no change requested, stay in current mode? > The > second one seems to be what the portlet wants in that case. > 3. producer does not replace at all > Here the consumer needs to check while processing the URL that the > mode > {wsrp-mode} was a template-non-change and interpret this as "stay in > current mode". > > > > > > > > > 2 & 3 imply that "" and "{wsrp-mode}" are reserved mode strings and > are not > allow to use for mode names (don't think one would ever want to name > modes > that way :-) ) > > > > > > > > > I think 1 is the cleanest one, others seem to impose various > interpretation > possibilities. > > > > > > > > > It seems that the Citrix Producer chooses 3. for all replacement > tokens in > templates in such cases? > > > > > > > > > Mit freundlichen Gruessen / best regards, > > > > > > > > > Richard Jacob > ______________________________________________________ > IBM Lab Boeblingen, Germany > Dept.8288, WebSphere Portal Server Development > Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 > Email: mailto:richard.jacob@de.ibm.com > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster > > > of the OASIS TC), go to > > >http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php > > > > . > > > > > > > > > > > > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]