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
<>
11/07/2003 12:14 PM
To
cc
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.
