[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
Here are some arguments for replacing with current values or ""
- The template includes the mode/state token in the path string of a
template. For example
http://foo.com/myportlet/{wsrp-mode}
This won't work since braces get URL-encoded. To make it correctly, the
consumer will have to unencode the path. This URL will be resolved
correctly if the token is replaced with the current value or with an
empty string.
- The template includes the mode/state token as a query string. For example
http://foo.com/portal?page=2&portlet=myportlet&mode={wsrp-mode}
This case is simpler. For the consumer, a "mode=wsrp:help" indicates a
transition, a "mode=" indicates no transition. But the consumer must
explicitly check for a value "{wsrp-mode} for the "mode" query param.
Regards,
Subbu
Richard Jacob wrote:
> I agree with Andre.
> As I stated in onother posting (seems we broke the thread), the consumer
> must deal with this issues anyway (therfor I don't see any additonal value
> in producer replacing with "").
>
> 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 03:24 |
> | | PM |
> |---------+---------------------------->
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: wsrp-interop@lists.oasis-open.org |
> | cc: |
> | Subject: 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:subbu@bea.com]
> Sent: 11 November 2003 14:04
> To: wsrp-interop@lists.oasis-open.org
> 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: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
>
>
>>.
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
> 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]