Next in thread →
Next in month →
RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates
While
I agree that the expected behaviour in the absence of a mode/windowState
assertion is to stay in the same mode/windowState, I do not see any need to
semantically equate setting the current mode/windowState (e.g.
newMode=wsrp:help - where the request's mode was help) with the portlet
asserting no value (e.g. newMode={wsrp-mode} or newMode=""). By allowing for a
looser "don't care", I was raising the possibility that a portlet may be
more tolerant of an consumer initiated change when not setting the
mode/windowState on a URL, but I think we would have to review this possibility
in future to allow the consumer to properly signal changes (e.g. using eventing)
- not simply changing modes at its whim.
regards,
Andre
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: 11 November 2003
19:09
To:
Subject: RE:
[wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up:
templates
The semantics
of a mode or windowState having a value either in an URL or a return from
performBlockingInteraction is that the portlet is requesting a change to a
particular new mode or windowState. The inverse is implied, namely that the
absence of such a request is a request to stay in the same mode or
windowState. In all cases, these are just a request of the Consumer, but we
did insert language saying that the Consumer needs to respect these requests
other than in exceptional circumstances. The net is that the portlet developer
can reasonably depend on a particular behavior while the Consumer still has
the right to make other choices when necessary.
By the way, I prefer 3b as this is consistent with the
Producer always replacing the portlet url parameters in templates. When the
portlet (or Consumer) hasn't supplied a particular value, a value of "" is
always used. I also agree that Consumers should be prepared for 3a as the spec
leaves underspecified.
Rich
Andre Kramer
<>
11/11/2003 12:10 PM
To
cc
Subject
RE: [wsrp-interop] Re:
[wsrp-conformance] RE: [wsrp-interop] foll
ow-up: templates
1,
2, 3a and 3b are all fine.
As I said previously, I prefer 4c, as a producer that does
care can chose to do 4a (which I agree is the safest bet for mode navigational
links cf your example). However, if you (and Subbu or others) feel strongly
that 4b is better then we could make that the case for wsrp-mode (and
even wsrp-windowState).
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:]
Sent: 11 November 2003
14:38
To: Subbu
Allamaraju
Cc:
Subject: Re: [wsrp-interop] Re: [wsrp-conformance] RE:
[wsrp-interop]
foll ow-up:
templates
Ok, then we're all on the same track, I think.
Let me try to briefly summerize the options we
have set up and the
differences
that remain:
1. there is a group
of tokens which must be replaced by valid values in any
case
2.
there is a group of tokens which may not be replaced because a)
the
producer/portlet does not want
to, does not have the information or is
meaningless in some cases
3. two option for those token which can't be filled with
meaningfull
values:
a) portlet/producer leaves the {wsrp-..} token
to indicate "not set, don't
bother
with it"
b) portlet/producer
substitutes {wsrp-..} to "", to indicate "not set,
don't bother with it"
4. what to do with mode and window states?
a) must always be set by the
producer/portlet
b) choose option
3a) or 3b) to indicate not set, Consumer interprets as
"stay in same mode/window state"
c) choose option 3a) or 3b) to indicate not set,
Consumer interprets as
"don't
care, Consumer's decision"
I'm just thinking loud: Consumers must always process URLs and
interpret
the various values, it
would also need to interpret "" or "{wsrp-...}". So
the consumer couldn't care less? What makes it an
advantage for producer's
to
activly do the replacement for all tokens (although easily
possible
since the producer does
the replacing for some of them anyway). I think I
don't see an advantage here therefor could happily
live with 3a).
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:
|---------+---------------------------->
| |
Subbu Allamaraju |
| |
<> |
|
|
|
| |
11/11/2003 03:03 |
|
| PM
|
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To:
|
| cc:
|
| Subject: Re:
[wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Richard,
By removing, I meant to replace with an empty string, and the
rules are:
{wsrp-urlType} - always replaced
{wsrp-url} - replaced for resource URLs. Remove for
other templates.
{wsrp-portletHandle} - always replaced
{wsrp-userContextKey} - always replaced
{wsrp-portletInstanceKey} - replaced if known,
removed otherwise
{wsrp-sessionID}
- replaced is there is a session, removed otherwise
{wsrp-navigationalState} - replaced with navigational
state, removed if
there is no
state
{wsrp-interactionState} -
replaced with interaction state, removed if
there is no state
{wsrp-requiresRewrite} - replaced with a true or false in resource
URLs.
Removed in other
URLs
{wsrp-mode} - replaced with
current or new values. Removed from resource
URLs (?)
{wsrp-windowState} - replaced with current or new values. Removed
from
resource URLs (?)
{wsrp-secureURL} - replaced with true or
false
{wsrp-fragmentID} - replaced
if there is a fragment. Removed otherwise
So, in your example, the above rules translate to
http://my.com/portal/anzeigeistgleichblockingAction/neuerZustandentsprichtview/fenstergroessesollteseinmaximized/blabla
when the current mode is "view", window state "maximized",
urlType is
blockingAction, and
there is no portletInstancekey.
Regards,
Subbu
Richard Jacob said the following on 11/11/2003 02:36
AM:
>Subbu,
>
>by remove you
mean replace {wsrp-...} with ""?
>If so, yes this could be an option we were
discussing.
>
>If you mean to try to remove the "mode
change request" (didn't find a
>better wording here) in the URL then you can't because for
the
>producer/portlet all
characters outside the {..}-tokens are constants and
>must not be changed.
>Btw. it would be even possible to remove because
you don't know what the
>cosumer uses its own constants to mark mode changes in its
URLs, it only
>needs the token
to be replaced.
>You could also
break the consumer's URL.
>Example template:
>http://my.com/portal/anzeigeistgleich{wsrp-urlType}/neuerZustandentspricht{wsrp-mode}/fenstergroessesolltesein{wsrp-windowState}/blabla
>
>{wsrp-portletInstanceKey}
>
>Which of these
would you remove?
>
>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:
>
>
>|---------+---------------------------->
>| |
Subbu Allamaraju |
>| |
<> |
>| |
|
>|
| 11/11/2003 04:40 |
>| |
AM
|
>|---------+---------------------------->
> >
--------------------------------------------------------------------------------------------------------------------------------------------------|
> |
|
> |
To:
|
> |
cc:
|
> | Subject:
Re: [wsrp-interop] Re: [wsrp-conformance] RE:
[wsrp-interop] foll ow-up: templates
|
> >
--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
>Few
comments
>
>1. It is fairly trivial for a producer to replace
wsrp-mode and
>wsrp-windowState
tokens with either new values or current values. I
>would argue against introducing special tokens
(such as wsrp:null) or
>replacing with " ", as this would increase the complexity for
the
>consumer. If replacing
these tokens with current values (when there is
>no transition) is considered risky, why not remove
those tokens?
>
>2. For tokens under (a), if the producer
is unable to set a value for a
>token it should remove it. An example is
wsrp-portletInstanceKey.
>
>To keep the
rules simple and easy to understand, why not remove unset
>tokens (I'm excluding (b) and (c))?
>
>Regards,
>
>Subbu
>
>Richard Jacob
wrote:
>
>
>
>>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).
>>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).
>>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.
>>
>>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".
>>
>>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.)
>>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
>.
>
>
>
>
>
>
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.
Next in thread →
Next in month →