[
https://issues.apache.org/jira/browse/BEEHIVE-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers closed BEEHIVE-1031.
----------------------------------
Resolution: Fixed
Fix Version/s: V.Next
Closing... This has been fixed for a while. In svn revision 476221, the
ScopedRequest.getNamesOfRemovableAttributes() method returns names of
attributes that do not need to be saved in a session or restored later for a
follow up refresh request. They are not required for the refresh request.
The MockPortletTag class was updated to use this new method for the mock portal
tests.
> Develop an API for marking scoped request attributes as "persistable".
> ----------------------------------------------------------------------
>
> Key: BEEHIVE-1031
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1031
> Project: Beehive
> Issue Type: Improvement
> Components: NetUI
> Affects Versions: 1.0, 1.0.1
> Reporter: Carlin Rogers
> Assignee: Carlin Rogers
> Fix For: V.Next
>
>
> We need a way for a portal framework using the NetUI Scoping support to be
> able to determine which request attributes should be persisted and which
> could be removed before persisting the attributes.
> Here's some detail from Rich and his design document...
> http://wiki.apache.org/beehive/Design/PortletScoping - see the third
> paragraph and below under "Issues and Future Directions". Basically, the
> choice of which attributes are persisted is in the developer's control, but
> we'll offer an API that allows setting of a "hint" for a persisted request
> attribute, and we'll use this API for attributes NetUI sets as necessary
> (e.g., the attribute that holds Page Inputs).
> A dev would be able to figure out which attributes we expect to be persisted:
> in the Map we pass you from ScopedRequest.getAttributeMap(), the attributes
> that extend ReconstructibleAttribute are the ones from NetUI that you should
> definitely persist. This eliminates the need to know our internal attribute
> names.
> When you do persist a ReconstructibleAttribute, you should call
> dropAttribute() on it -- we'll automatically reconstruct it as needed during
> ScopedRequest.getAttribute().
> Rich also tried to start up a discussion on the dev list earlier in August,
> http://mail-archives.apache.org/mod_mbox/beehive-dev/200509.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
