Session scoped transient properties.

[Michael Freedman <michael.freedman@oracle.com>]

Currently we don't allow getMarkup and getResource to return 
transientPropertyUpdates; only performBlockingInteraction and 
handleEvents can.  Should we remove this restriction?

Currently, we don't allow navigational state, mode, window state changes 
from getMarkup/getResource because we can't ensure the consumer can 
implement reasonable semantics.  To a lesser extent we disallow this 
because our model discourages state changes during render.  However, 
because we can't control internal producer session state this is a 
convention not something that can be fully enforced.

I believe setting transient session properties at GM/GR time can be 
semantically defined -- its no different then doing such a thing locally 
in a concurrent world.  I.e. the consumer honors such sets immediately 
[as with handleEvents].  So, though we would continue to want to 
discourage transient property state changes should we prevent it merely 
on the grounds that its not our preferred model?

What we lose by having this restriction are degrees of freedom in how 
environments built on top of wsrp that ease portlet development will 
expose this concept.  One reasonable model [that JSR 286 is currently 
advocating] is to not distinguish within portlet code between transient 
session properties and producer session properties.  From a code 
perspective there are just session properties.  The code reads/writes 
these values without explicit knowledge as to whether the value is 
shared with the consumer.  That detail is described in 
configuration/metadata. The JSR 286 container is responsible for moving 
the appropriate values to/from the session from/to the consumer.  Like 
wsrp, the jsr discourages session state changes during 
render/getresource.  Also like wsrp it doesn't prevent such changes.  
With the current restriction the JSR is faced with either tightening its 
requirements to throw an exception if any session writes are attempted, 
allowing the local writes but throw an exception for those session 
properties that are shared [transient], or merely updating the values 
locally but not returning such state to the consumer [meaning these 
updates will be lost on the next request as the transient properties are 
pushed again with the old values].  All three of these are behaviors 
will be foreign to java [web app] developers. 
   -Mike-