OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] follow-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:richard.jacob@de.ibm.com
>
>
>|---------+---------------------------->
>|         |           Subbu Allamaraju |
>|         |           <subbu@bea.com>  |
>|         |                            |
>|         |           11/11/2003 04:40 |
>|         |           AM               |
>|---------+---------------------------->
>  >--------------------------------------------------------------------------------------------------------------------------------------------------|
>  |                                                                                                                                                  |
>  |       To:       wsrp-interop@lists.oasis-open.org                                                                                                |
>  |       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: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
>
>  
>
>>      .
>>
>>
>>
>>
>>
>>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
>.
>
>
>
>
>  
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]