Hi Rich,
too me the behavoir is still not quite clear.
1. From an end user perspective I would have assumed that whenever I
change the navigational state of a portlet this would also result in a
new request. What does it mean to be in the same request cycle, but
after the user has clicked on a button changing the navigational state
the portlet now renders the data of a different customer?
2. Why is it the same request cycle when I change from page A to page B
and back to page A. According to the current text the portlet on page A
would still be in the same request cycle as no action or event had
occured since it was last rendered. And how can the consumer keep track
of this information efficiently? In order to support this flag and
browser back button it would need to be encoded in the URL for each
portlet the user has visited during the whole lifetime of a session.
3. What is the value for the initial portlet rendering? There was no
action or event, so it is no new lifecycle? Seems strange to me as there
is no "old lifecycle" to refer to.
4. How would the consumer know if the user got to the page where the
portlet is placed and needs to be rendered via a bookmark or via user
interaction? If the consumer needs to encode this flag in the URL it
seems to me quite hard to implement.
I would like to get the nav state changs added to the criteria for being
a new request and change the MUST to a SHOULD and explain that the
consumer may not send a "true" in every case. Of course this change
would mean that consumers will behave differently, but I can't imagine
that everyone can and will implement the current proposal as it seems
quite expensive to me.
Stefan
Rich Thompson wrote:
>
> For those not on the Interfaces SC call today, the use cases regarding
> Producers who have a concept of a user-request scope needing some
> support from Consumers was discussed. There was a building consensus
> toward having the Consumer supply an ID which changes only on action or
> event processing, though most wanted to see a proposal in the context of
> the spec and think through what the impacts of those changes would be on
> reasonable Consumer implementations before deciding whether or not to
> include such support in v2. I agreed to draft such a proposal, but had a
> problem with the scenario of a End-User jumping to a different state of
> the page. This can easily happen via a bookmark, but also may happen
> when the browser's back button is pushed. This caused me to change the
> proposal to a style where the Consumer indicates to the Producer when it
> knows a new requestCycle is starting via a boolean rather than being
> more definitive by supplying an ID. I left the original attempt in (with
> a strike through the text) so that people can easily consider that
> option as well.
>
>
>
> Rich
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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
