RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] follow-up: templates

[Andre Kramer <andre.kramer@eu.citrix.com>]

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>

11/07/2003 12:14 PM

To	wsrp-interop@lists.oasis-open.org
cc	wsrp-conformance@lists.oasis-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.