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] spec-2.0-draft-05: RuntimeContext: public parameters question

The semantics for public parameters is that the Consumer decides what, if any, values to provide for each invocation of the portlet. In particular, the Consumer may have previously sent a value and decide that it no longer has a value to send (e.g. the source for the supplied value has been cleared). The key is that the Portlet should react to the value supplied on the current invocation rather than caching some previous value and reusing it. Since the will certainly be cases where a Consumer does not supply a desired value, portlets should design in a graceful fallback (default value or UI implications) for when there is no supplied value. I would note that presenting the user with previously used values for defining a default is not a bad option. This would imply storing previously supplied values, but does not violate the semantics because the portlet is not using a previous value ... it is merely providing reasonable prompts for the user to define an underlying default value. I suspect this should be covered in a new Primer section dealing with public parameters.


Stefan Hepper <sthepper@hursley.ibm.com>

03/09/05 02:13 AM

WSRP TC <wsrp@lists.oasis-open.org>
[wsrp] spec-2.0-draft-05: RuntimeContext: public parameters question

what is the intended behavior of public params across requests? The spec
currently states that the portlets should not store these params as the
consumer will provide them in each request. Does that mean that the
portlet can count on getting this param from a specific producer after
the first time it receives this param?
How can the portlet find out which params the consumer will support? E.g
if the portlet knows that the consumer will not provide the zip code it
can output a msg and a link to the edit mode to preset some zip code.
When it knows that the consumer provides the zip code but the current
request is lacking it the portlet can output some warning that the zip
code was not available.


To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org

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