If the resource response returns a portlet context with new values for
the portlet handle or state, I assume the cache should be invalidated.
However, there are cases where the portlet's handle does not change:
- state change is read-write
- the resource makes other changes to the portlet's markup through
a non-spec mechanism (e.g. producer session)
In these cases we do not currently have a mechanism to invalidate the
cache. This is regardless of the usage of the resource (verb and
placement).
Some possible solutions:
- Do nothing, force the portlet developer to turn off caching when
doing such operations
- Make a note, stating that caching may cause unexpected results
- Add a clearPortletCache attribute to ResourceContext
- Use the portletContext as semaphore to clear the cache, Add a
statement like:
- If the portlet context is returned the consumer SHOULD clear
the portlet's cache, regardless of whether the handle and state values
have changed.
Nate
Michael Freedman wrote:
4762C7FC.1050001@oracle.com" type="cite">I would
not make this editorial change as I think it makes things more
confusing not less -- as I suspect most portlets that use getResource
to further serve parts of their (inline) content will likely not rely
on consumer caching.
-Mike-
Stefan Hepper wrote:
Since we are in the progress of making some
editorial changes :-) here something we just noted:
5.2.1.2 states:
"Consumers should be aware that invoking performBlockingInteraction
and/or handleEvents may cause cached markup to become invalid."
I think this should be extended to also include getResource triggered
via HTTP method POST, PUT, DELETE as in that case the portlet will
likely make state changes that render the previously cached markup
invalid.
Stefan
---------------------------------------------------------------------
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
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |