Title: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
Please note my example was for window states (not modes) and for a mode that the consumer had extra knowledge about (some sophisticated help system). Why constrain what we will be able to do in future?
regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: 11 November 2003 14:24
To:
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:
>
>
>|---------+---------------------------->
>| | Andre Kramer |
>| | <andre.kramer@eu.|
>| | citrix.com> |
>| | |
>| | 11/11/2003 09:46 |
>| | AM |
>|---------+---------------------------->
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: |
> | 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:]
>Sent: 10 November 2003 18:05
>To: Andre Kramer
>Cc:
>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:
>
>
>
>
>
>|---------+---------------------------->
>| | Andre Kramer |
>| | <andre.kramer@eu.|
>| | citrix.com> |
>| | |
>| | 11/10/2003 05:49 |
>| | PM |
>|---------+---------------------------->
> >
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
> |
>|
>
>
> | To:
>|
>
>
> | 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:]
>Sent: 10 November 2003 15:11
>To: Andre Kramer
>Cc:
>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:
>
>
>
>
>
>
>
>
>|---------+---------------------------->
>| | Andre Kramer |
>| | <andre.kramer@eu.|
>| | citrix.com> |
>| | |
>| | 11/10/2003 10:40 |
>| | AM |
>|---------+---------------------------->
> >
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
> |
>|
>
>
>
>
>
> | To:
>|
>
>
>
>
>
> | 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:]
> Sent: 07 November 2003 18:22
> To:
> 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
> <>
>
>
> To
> 11/07/2003 12:14 PM
> -open.org
> cc
> [email protected]
> 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:]
> Sent: 07 November 2003 16:25
> To:
> Cc:
> 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:
>
>
>
>
>
>
>
>
> 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.
