I agree completely. The issue comes down to whether our protocol
enforces the convention or merely identifies it as best practice. If
we allow the return of transientProperties I would expect us to provide
clarifying terms that reference a best practice statement (or some such
thing). As for the unexpected behavior: Noted that the problem is
worse, but in many portlet environments changing session state can
impact other portlets in that producer and hence portlet developers
have to recognize/avoid getting themselves into a fix. Which brings us
back to the question then of why should we allow this in the first
place? I believe you answered that in your message when you described
that in the existing web world containers pass this issue to component
developers. The reality is these are some of the same component
developers wanting to provide portlets. Many come from a
perspective/expectation that they should be able to adapt their
existing component code quickly and easily into the portlet environment
(some in fact don't even know they are running as portlets as that
adaption is done underneath them by the MVC system/bridge technology).
Right now our design forces these vendors to rewrite their existing
work which delays their migration.
-Mike-
Rich Thompson wrote:
This likely revolves around how one
views idempotency and the WSRP protocol.
It has been frequently argued that
there
is a straight-forward mapping of the HTTP verbs to WSRP operations and,
in particular, that getMarkup and getResource are idempotent
operations.
Whether one agrees with that assertion or not, there is the next level
of issue in that many sites relax idempotency to only include
transactional
items and not 'trivial' things (such as hit counters) or the caching of
items in a user session. It is often these use cases that drive
container
decisions to not enforce the idempotent requirements of certain
interactions,
but rather to pass the issue on to component developers. At this
philosophical
level, a key question is whether adding the ability to return
transientProperties
with response to GM and GR wouldn't be a declaration that these aren't
really idempotent interactions. (The "container" is allowing
non-idempotent behavior without knowledge as to whether it will be used
in a "transaction" manner ... and components can not determine
this either.)
On a practical level, it seems like
adding this feature would cause page refreshes to exhibit unexpected
behavior.
Consider when portlet A generates its markup and then portlet B updates
a transient property both receive. A page refresh would cause a change
in the markup from portlet A which would likely be unexpected in many
cases
and would definitely exhibit that the page wasn't conforming to
idempotent
requirements. I'm not sure this is entirely a bad thing, but it
shouldn't
be taken lightly either.
Rich
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-
---------------------------------------------------------------------
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
|