… And there you said it: Public
parameters have become a transparent-to-the-Consumer state of the portlet,
rather than the transparent-to-the-Portlet state of the consumer.
I just feel we need to keep these things
out in the open rather than try to avoid actually saying them. Because I have
no doubt that the next question that will be asked is what happens if the
portlet “changes” a public parameter that the consumer is not aware
of.
Yossi.
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Wednesday, June 15, 2005
7:03 PM
To: WSRP TC
Subject: Re: [wsrp] Additional use
cases for issue #44 (set new public params)
I think the use case for public parameters on render
URLs also relates to them effectively being an extension to the opaque navState
of WSRP v1. One can change the opaque portion of the navState on render URLs,
why not the transparent-to-the-Consumer portion?
Rich
Stefan Hepper
<sthepper@hursley.ibm.com>
06/15/05 11:51 AM
|
To
|
Rich Thompson/Watson/IBM@IBMUS
|
cc
|
WSRP TC <wsrp@lists.oasis-open.org>
|
Subject
|
Re: [wsrp] Additional use cases for issue #44
(set new public params)
|
|
It
also makes a hugh difference from the HTTP protocol point of view as
pbia need to be implemented as HTTP POST whereas
you would only need
HTTP GETs for changing public parameters.
Otherwise how could you comply
with the W3C architecture?
Also search engines like google very much count on
this distinction in
order to follow links.
Stefan
Rich Thompson wrote:
>
> I think the use case for any of them being on
the URL is render URLs.
> Specifying them on the URL allows such inputs
while short-circuiting the
> action processing step(s) of the protocol,
resulting in improved
> cacheability and performance.
>
> Rich
>
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/15/05 11:15 AM
>
>
> To
>
Rich Thompson/Watson/IBM@IBMUS, "WSRP TC"
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
>
RE: [wsrp] Additional use cases for issue #44 (set new
public params)
>
>
>
>
>
>
>
>
> I understood it to be an optimization. i.e.
the consumer can indicate
> that it is willing to accept a new window
state or mode switch by
> calling performBlockingInteraction with the
values supplied on the URL.
> I’m not convinced that’s the case
for public params in general.
>
> --
Andre
>
>
>
------------------------------------------------------------------------
>
> *From:* Rich Thompson
[mailto:richt2@us.ibm.com] *
> Sent:* 15 June 2005 16:04*
> To:* WSRP TC*
> Subject:* RE: [wsrp] Additional use cases for
issue #44 (set new public
> params)
>
>
> The use cases Stefan posted to start this
thread need public parameters
> to be set on the URL.
>
> Other other question I would ask is why
doesn't the same argument apply
> to mode and windowState? (i.e. I am arguing
for consistency as well as
> efficiency)
>
> Rich
>
> *"Andre Kramer"
<andre.kramer@eu.citrix.com>*
>
> 06/15/05 09:35 AM
>
>
> To
>
Rich Thompson/Watson/IBM@IBMUS, "WSRP TC"
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
>
RE: [wsrp] Additional use cases for issue #44 (set new
public params)
>
>
>
>
>
>
>
>
>
>
>
>
> I can subscribe to the philosophy of portlets
requesting updates to
> public parameters but why do they need to be
able to request update via
> markup URLs (i.e. on link activation).
Surely, a much simpler model
> would be just to let
performBlockingInteraction and friends
> return/output as well as take as input public
parameters? That would tie
> into the event model better as portlets would
have the chance to
> coordinate such updates if an update was a
subscribable event.
>
> Regards,
> Andre
>
>
>
>
>
------------------------------------------------------------------------
>
> *
> From:* Rich Thompson [mailto:richt2@us.ibm.com]
*
> Sent:* 15 June 2005 14:25*
> To:* WSRP TC*
> 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 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
<michael.freedman@oracle.com>*
>
> 05/24/05 07:55 PM
>
>
>
>
> To
>
WSRP TC <wsrp@lists.oasis-open.org>
> 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
>
---------------------------------------------------------------------
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