OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Additional use cases for issue #44 (set new public params)



It sounds like you are linking the definition of what public parameters are with some concept of where the values are derived from. I don't see how allowing the values to be derived from Portlet generated artifacts changes the definition of what public parameters are.

Rich



Subbu Allamaraju <subbu@bea.com>

06/15/05 12:04 PM

To
WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Additional use cases for issue #44 (set new public params)





I agree. Sec 6.1.2 clearly states that public parameters are "aspects of
consumer managed state that is supplied to the portlet on each
invocation". So, if we think it is valuable for portlets to influence
public parameters (of any portlet?), then, we must revisit the
definition of public parameters.

Regards,
Subbu

Andre Kramer wrote:

> 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]