[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
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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]