[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
Didn't we have a lengthy debate (raised by Alejandro) in May about
consistent user experience? I don't recall how it was started, but
remember some concerns.
Regards,
Subbu
Andre Kramer wrote:
> Please note my example was for window states (not modes) and for a
> mode that the consumer had extra knowledge about (some sophisticated
> help system). Why constrain what we will be able to do in future?
>
> regards,
> Andre
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 11 November 2003 14:24
> To: wsrp-interop@lists.oasis-open.org
> Subject: Re: [wsrp-interop] Re: [wsrp-conformance] follow-up: templates
>
>
>
> To keep consistent behavior, it is safe to either replace with current
> values or empty strings when there is no transition request. I agree
> with Richard's use case. Allowing the consumer to pick any mode/state
> could lead to inconsistent user experience.
>
> Regards,
>
> Subbu
>
> Richard Jacob said the following on 11/11/2003 06:43 AM:
>
> >Ok, this is a different semantic here - other then the "no-change"
> semantic
> >we discussed before.
> >I think the intent of our and JSR168 semantic is that if there is no
> mode
> >parameter on the URL then the portal (or consumer) will (or should)
> remain
> >in the same mode as it was (that's different to the "don't care"
> >semantics).
> >We say in 10.2.1.4 "Activating this URL includes a request to CHANGE the
> >mode parameter in MarkupParams into the mode specified [...]".
> >So one could interpret (although we are not explicit) the absence of
> mode
> >(or the non-replacement to stay in the template scope) is a request
> to stay
> >in the same mode.
> >
> >We need to be carefull here, otherwise we might observe different
> >behaviours for different producer-consumer pairs.
> >One use case:
> >Portlet has multiple pages for edit mode linked via navigational links
> >(prev, next, etc.).
> >The portlet does not place mode parameter in the navigational URLs.
> >User changes the portlets mode to "edit", via decoration. ->
> >markupParams.mode=edit
> >User clicks on next in edit mode (without specifying mode=wsrp:edit
> in the
> >link), now when the consumer may choose what to do, it could change
> to view
> >mode -> markupParams.mode=view.
> >This would prevent the user from ever getting to the next page.
> >This would enforce the portlet programmer to *always* code the mode
> >parameter in URLs (which is not the case either in the JSR168 spec
> nor in
> >our spec).
> >
> >And in this case this leads us back to the discussion whether we should
> >enforce the producer to *always* replace these {wsrp-...} tokens in
> >templates :-)
> >Therefor I would say that the semantic for not having these params in
> the
> >URL means "no change" rather then "don't care" (if we choose to do the
> >non-replacement processing).
> >
> >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 09:46 |
> >| | AM |
> >|---------+---------------------------->
> >
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
> >
> |
> |
>
> > | To:
> wsrp-interop@lists.oasis-open.org
> |
>
> > |
> cc:
> |
>
> > | Subject: RE: [wsrp-interop] Re: [wsrp-conformance]
> follow-up:
> templates
> |
>
> >
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
> >
> >
> >
> >
> >Richard,
> >
> >
> >On the "always transition" option you raise, I supposed it would be
> useful
> >for a portlet to say "I don't care about the mode / window state" on
> a URL.
> >When we introduce events we may be able to make use of this extra
> semantic
> >information. For 1.0, a link with "mode=wsrp:help&windowState
> >={wsrp:windowState}" allows the portal to select the best window
> state for
> >displaying help but "mode=wsrp:help&windowState=wsrp:normal" would
> >constrain the portal to call the portlet in the normal window state just
> >because that was the current mode when the url was rendered.
> >
> >
> >regards,
> >Andre
> >
> >
> >-----Original Message-----
> >From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
> >Sent: 10 November 2003 18:05
> >To: Andre Kramer
> >Cc: wsrp-interop@lists.oasis-open.org
> >Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop]
> >foll ow-up: templates
> >
> >
> >
> >
> >
> >
> >my comments in <rj>
> >
> >
> >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 05:49 |
> >| | PM |
> >|---------+---------------------------->
> > >
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
> >
> >
> > |
> >|
> >
> >
> > | To: wsrp-interop@lists.oasis-open.org
> >|
> >
> >
> > | cc:
> >|
> >
> >
> > | Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE:
> >[wsrp-interop] foll ow-up: templates
> >|
> >
> >
> > >
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
> >
> >
> >
> >
> >
> >
> >
> >(e) was just for catching tokens allowed by the grammar but not really
> >expected in templates, <ak> below.
> ><rj> agreed
> >Rich: is wsrp-Token not also a relict that should be removed from the
> spec?
> >
> ></rj>
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
> >Sent: 10 November 2003 15:11
> >To: Andre Kramer
> >Cc: wsrp-interop@lists.oasis-open.org
> >Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop]
> >foll ow-up: templates
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >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).
> >
> >
> >
> >
> >
> ><ak>I don't {wsrp-secureUrl} is sensible for templates as we have both
> >secure and normal versions for constructing urls.</ak>
> >
> >
> >
> >
> >
> ><rj> agreed, I missed the fact that even for default templates we have a
> >secure one :-), given that I would say it fits in e) as you say it </rj>
> >
> >
> >
> >
> >
> >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).
> >
> >
> >
> >
> >
> ><ak> we did use the "wsrp-" to mean our URI and "{" is used in
> matching so
> >we are on pretty safe ground here.</ak>
> >
> >
> >
> >
> >
> ><rj> agreed </rj>
> >
> >
> >
> >
> >
> >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.
> >
> >
> >
> >
> >
> ><ak>custom modes & window states need to be declared in service/portlet
> >descriptions which also helps.</ak>
> >
> >
> >
> >
> >
> ><rj> agreed </rj>
> >
> >
> >
> >
> >
> >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".
> >
> >
> >
> >
> >
> ><ak>{wsrp-token} is unneeded and {wsrp-fragmentID} seems currently
> >underspecified.</ak>
> >
> >
> >
> >
> >
> >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.)
> >
> >
> >
> >
> >
> ><ak>I would go for "MUST be either the wsrp-defined ones or custom ones
> >supported by the producer IF replaced". Here the "wsrp-defined" is an
> >unfortunate use of "wsrp-". </ak>
> >
> >
> >
> >
> >
> ><rj> ok, so here you go for the option modes/states do not need to be
> >replaced, right? What about my question for always to transition even
> if it
> >
> >is mode x -> mode x ?</rj>
> >
> >
> >
> >
> >
> >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]