Re: [wsrp] spec-2.0-draft-05: RuntimeContext: public parameters question

[Rich Thompson <richt2@us.ibm.com>]

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.

Rich

Stefan Hepper <sthepper@hursley.ibm.com>

03/09/05 02:13 AM

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

Rich,
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.

Stefan


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