[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
I agree with Andre. As I stated in onother posting (seems we broke the thread), the consumer must deal with this issues anyway (therfor I don't see any additonal value in producer replacing with ""). 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 03:24 | | | PM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-interop@lists.oasis-open.org | | cc: | | Subject: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates | >--------------------------------------------------------------------------------------------------------------------------------------------------| We seem to be in danger of introducing considerable complexity. Why not just allow both replace by (1) "" and (2) leave as is ({wsrp-xyz} allowed in urls in markup)? It seems much simpler for the consumer to handle both (1 & 2) and guards against errors (such as a producer not looking for a "wsrp-url" in a defaultTemplate when used for an action). That way we maximize interoperability and remove any need for extra conformance statements (that need errata to the spec). regards, Andre -----Original Message----- From: Subbu Allamaraju [mailto:subbu@bea.com] Sent: 11 November 2003 14:04 To: wsrp-interop@lists.oasis-open.org Subject: Re: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates Richard, By removing, I meant to replace with an empty string, and the rules are: {wsrp-urlType} - always replaced {wsrp-url} - replaced for resource URLs. Remove for other templates. {wsrp-portletHandle} - always replaced {wsrp-userContextKey} - always replaced {wsrp-portletInstanceKey} - replaced if known, removed otherwise {wsrp-sessionID} - replaced is there is a session, removed otherwise {wsrp-navigationalState} - replaced with navigational state, removed if there is no state {wsrp-interactionState} - replaced with interaction state, removed if there is no state {wsrp-requiresRewrite} - replaced with a true or false in resource URLs. Removed in other URLs {wsrp-mode} - replaced with current or new values. Removed from resource URLs (?) {wsrp-windowState} - replaced with current or new values. Removed from resource URLs (?) {wsrp-secureURL} - replaced with true or false {wsrp-fragmentID} - replaced if there is a fragment. Removed otherwise So, in your example, the above rules translate to http://my.com/portal/anzeigeistgleichblockingAction/neuerZustandentsprichtview/fenstergroessesollteseinmaximized/blabla when the current mode is "view", window state "maximized", urlType is blockingAction, and there is no portletInstancekey. Regards, Subbu Richard Jacob said the following on 11/11/2003 02:36 AM: >Subbu, > >by remove you mean replace {wsrp-...} with ""? >If so, yes this could be an option we were discussing. > >If you mean to try to remove the "mode change request" (didn't find a >better wording here) in the URL then you can't because for the >producer/portlet all characters outside the {..}-tokens are constants and >must not be changed. >Btw. it would be even possible to remove because you don't know what the >cosumer uses its own constants to mark mode changes in its URLs, it only >needs the token to be replaced. >You could also break the consumer's URL. >Example template: >http://my.com/portal/anzeigeistgleich {wsrp-urlType}/neuerZustandentspricht{wsrp-mode}/fenstergroessesolltesein{wsrp-windowState}/blabla > >{wsrp-portletInstanceKey} > >Which of these would you remove? > >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 > > >|---------+----------------------------> >| | Subbu Allamaraju | >| | <subbu@bea.com> | >| | | >| | 11/11/2003 04:40 | >| | AM | >|---------+----------------------------> > > --------------------------------------------------------------------------------------------------------------------------------------------------| > | | > | To: wsrp-interop@lists.oasis-open.org | > | cc: | > | Subject: Re: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates | > > --------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > >Few comments > >1. It is fairly trivial for a producer to replace wsrp-mode and >wsrp-windowState tokens with either new values or current values. I >would argue against introducing special tokens (such as wsrp:null) or >replacing with " ", as this would increase the complexity for the >consumer. If replacing these tokens with current values (when there is >no transition) is considered risky, why not remove those tokens? > >2. For tokens under (a), if the producer is unable to set a value for a >token it should remove it. An example is wsrp-portletInstanceKey. > >To keep the rules simple and easy to understand, why not remove unset >tokens (I'm excluding (b) and (c))? > >Regards, > >Subbu > >Richard Jacob wrote: > > > >>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). >>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). >>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. >> >>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". >> >>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.) >>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 >. > > > > > >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]