Title: RE: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
We seem to be in danger of introducing considerable complexity. Why not just allow both replace by (1) "" and (2) leave as is ({wsrp-xyz} allowed in urls in markup)? It seems much simpler for the consumer to handle both (1 & 2) and guards against errors (such as a producer not looking for a "wsrp-url" in a defaultTemplate when used for an action).
That way we maximize interoperability and remove any need for extra conformance statements (that need errata to the spec).
regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: 11 November 2003 14:04
To:
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.
