Next in thread →
Next in month →
RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates
Title: 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.
-----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>
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>
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>
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>
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
.
Next in thread →
Next in month →