My comment was that requiring action
processing is always possible, but why would we require it in this case
and not for mode/windowState/navState changes?
Rich
Subbu Allamaraju <>
07/22/05 09:48 AM
To
cc
Subject
Re: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
Thinking aloud, can't we map render URL use cases to use pbia? The
reason for changing the value of a paramter could be the result of a
user interaction, which can then compute new values and return with pbia
response.
Subbu
Rich Thompson wrote:
>
> It is possible to drive every style of update through action processing,
> but I think that short changes the advantages of using render URLs
where
> they are appropriate.
>
> New navState can be specified on each URL (including render URLs),
why
> should not the Portlet be able to specify the shared version (PPs)?
>
> Rich
>
>
> *"Andre Kramer" <>*
>
> 07/22/05 08:02 AM
>
>
> To
> Rich
Thompson/Watson/IBM@IBMUS, <>
> cc
>
> Subject
> RE:
[wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44
> (set new public params)
>
>
>
>
>
>
>
>
> After reading your previous email, I was driving towards a similar
> recommendation for Portlets to “re-fresh” public parameters by return
on
> each WSRP interaction so that a consumer is more likely to forward
> values that have been recently actively returned and I agree this
means
> Portlets have to maintain/store public param values e.g. in navigational
> state. But, with such advice, I see no reason to have public parameters
> to visibly appear on URLs (rewrite expressions or templates) at all.
Why
> introduce a new encoding and (in markup) transport mechanism when
it
> seems a preferable Web Service (in SOAP response) encoding and transport
> is already available and recommended?
>
> Regards,
> Andre
>
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:] *
> Sent:* 22 July 2005 12:24*
> To:* *
> Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
> issue #44 (set new public params)
>
>
> The Interfaces SC discussion raised the question about the scope of
PPs
> set in this manner. Namely; does the Portlet need to keep specifying
the
> PPs on all subsequent requests or can it depend on the Consumer to
> resupply those values in the future (i.e. some scope, like user-session,
> becomes mandated).
>
> I think we should be careful to leave scoping questions up to the
> Consumer, but if PPs are to function as a coordination model, then
we
> also have to discourage Portlets from setting all PPs on every URL.
A
> model where Portlets are encouraged to store current PP values
> (preferably in navState) for use as default values should the Consumer
> not supply a value on a subsequent invocation and only do PP setting
> when a value needs to change accomplishes this. It removes setting
the
> value each time such that coordination happens in a more reasonable
> manner while also providing for reasonable user experience, even when
> the Consumer does not support and PP scope beyond the user interaction.
>
> Note: We could consider a model where Portlets MUST encode all PPs
on
> all URLs such that this supplies the scope, rather than the Consumer
> determining the scope, but that this fails as the Portlet might not
have
> access to all PPs (security and privacy reasons).
>
> Rich
>
> *Rich Thompson/Watson/IBM@IBMUS*
>
> 07/07/05 11:54 AM
>
>
> To
>
> cc
>
> Subject
> [wsrp-interfaces]
Fw: [wsrp] Additional use cases for issue #44 (set
> new public params)
>
>
>
>
>
>
>
>
>
>
>
>
>
> Reposting, as requested ...
> ----- Forwarded by Rich Thompson/Watson/IBM on 07/07/05 11:52 AM -----
>
>
*Rich Thompson/Watson/IBM@IBMUS*
>
> 06/15/05 09:24 AM
>
>
> To: WSRP TC <>
> cc:
> Subject: Re: [wsrp]
Additional use cases for issue #44 (set
> new public params)
>
>
>
>
>
>
>
> I had taken a to-do from the Interfaces SC to develop (in conjunction
> with Stefan, Richard and Mike) a proposal for this portion of Issue
#44.
> Here is that proposal: *_
>
> Philosophy:_* Since Public Parameters (PP) are another aspect of
> Consumer managed state that is exposed to Portlets (the other two
are
> modes and windowState), Portlets should be able to request changes
to
> PPs in much the same way as they do modes and windowStates (on URLs
and
> in responses from pbia and handleEvents). *_
>
> On URLs: (2 issues)_*
> 1. Need to encode 3 pieces of information (request to set a PP, the
> PPname and the PPvalue) into 2 places (name=value) when using a
> querystring and deal with the reduced set of characters allowed in
the
> path portion ('=' is not allowed). Templates also introduce an issue
> with how to encode multiple PPs ... preferably with the Template only
> having a single placeholder.
> -Proposal:
> 1. All public parameters specified on a URL are concatenated in the
form
> of "PPname1=PPvalue1&PPname2=PPvalue2".
> 2. The resulting string is URL encoded (changes '=' into %3D and '&'
> into %26) to make it valid in both the querystring and path portions
of
> a URL.
> 3. This URL encoded string becomes the value for the
> wsrp-publicParameter URL parameter, regardless of whether template
> processing or Consumer URL rewriting is in use.
>
> 2. How to encode complex PPvalues? I suggest serializing the PPvalue
to
> XML and URL encoding this XML. The Consumer would then receive the
PP,
> recognize it is of a complex type (based on PPname) and decode the
> PPvalue to get the XML. *_
>
> On Operation responses:_*
> 1. Return PP requests via a field much as newMode and newWindowState
> request updates to those aspects of Consumer managed state. Suggest
this
> field be of type QNamedStringArray, though it could be an array of
> NamedString if we do not want to introduce a usage of a type from
the
> 'extra' namespace.
>
> Rich
>
> *Michael Freedman <>*
>
> 05/24/05 07:55 PM
>
>
>
>
> To
> WSRP
TC <>
> cc
>
> Subject
> Re:
[wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
>
>
>
>
>
>
>
>
>
>
> I too am interested in hearing people's current opinions. Our
early
> coordination discussions considered this carefully. It was decided
at
> that time to not support two coordination models that delivered
> equivalent function. Though I pushed strongly for such a parameter
> style mechanism, the subcomittee preferred Events because it not only
> allowed state to be transferred but also actions. The current
public
> parameter model was introduced by me later and was crafted specifically
> to not step on the the toes of Events.
>
> To extend this conversation I would like to pose:
> 1. We consider whether publicParameters
should be QNames so they
> can be shared/reused across producers. Note: this is likely
needed
> whether we stick with events or add the ability to encode a public
> parameter directly in the URL.
> 2. We consider adding a new "defined
event" called
> publicParameterValueChanged. The payload of this event would
be the
> QName of the parameter and an Object any holding the parmeter value
> [though it might be nice to support our Any/String optional pair style
> here].
> 3. We consider defining the meaning of
publicParameter whose
> capability contains the value "required" as meaning that
normal usage of
> this portlet requires the consumer to provide this value. The
portlet
> would still have to deal with situations in which this wasn't provided
> but likely an end-user would consider this usage crufty/abnormal.
For
> example if a portlet required a CustID parameter and didn't receive
one
> it could display a view that asks for a custID. The key here
by saying
> "required" [we can choose a different capability name] the
consumer can
> distinguish between those public parameters that have a secondary
impact
> on the portlet [optional] and those that have a primary or important
> impact [required].
> -Mike-
>
> Stefan Hepper wrote:
> Hi,
> I've some use cases that may be a good match for the ability to set
new
> public parameters by the producer and to encode public parameters
in
> URls by the producer.
>
> 1. displaying content based on a specific product id:
> - Portlet A allows to select a product from a list
> - User clicks on a specific product
> - Portlet B renders details of this product
> - Portlet C renders currently available number of items on stock for
> this product
> - user wants to bookmark this result in order to come back to product
> tomorrow
>
> implementation with events:
> Portlet A encodes the customer selection URLs as POST action links
> Portlet A receives a performBlockingInteraction call
> Portlet A returns event productID=10
> Portlet B receive a blocking handleEvents call for productID=10 and
> returns new navigational state
> Portlet C receive a blocking handleEvents call for productID=10 and
> returns new navigational state
>
> implementation with public params:
> Portlet A encodes the product selection URLs as GET render links with
> the productID as public param
> Portlet A receives a render call with the public param productID=10
> Portlet B receives a render call with the public param productID=10
> Portlet C receives a render call with the public param productID=10
>
> which would be much more efficient and also consistent with the W3C
> architecture as links that do only change view state should be encoded
> as GET links.
>
>
> 2. display content based on a specific customer id
>
> 3. display content based on the selected state of a map
> portlet A displays a map of USA
> portlet B displays information on the selected state (# people
> registered, capital, ...)
> portlet C displays all IBM labs in that state
>
> and many more.
>
>
> This would allow to have some gobal navigational state that can be
set
> via URLs by portlets. Also portlets may want to set new public params
as
> a result of an blocking interaction or a handle event call.
>
>
> What do you think?
>
>
> Stefan
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in
> OASIS
> at: _
> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>
> ---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in
> OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
