[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
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:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 11/11/2003 09:46 |
| | AM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-interop@lists.oasis-open.org |
| 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:richard.jacob@de.ibm.com]
Sent: 10 November 2003 18:05
To: Andre Kramer
Cc: wsrp-interop@lists.oasis-open.org
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:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 11/10/2003 05:49 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: wsrp-interop@lists.oasis-open.org
|
| 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:richard.jacob@de.ibm.com]
Sent: 10 November 2003 15:11
To: Andre Kramer
Cc: wsrp-interop@lists.oasis-open.org
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: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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]