You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Max Starets (JIRA)" <de...@myfaces.apache.org> on 2010/12/08 23:02:02 UTC

[jira] Commented: (TRINIDAD-1764) System event listener state saving

    [ https://issues.apache.org/jira/browse/TRINIDAD-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969517#action_12969517 ] 

Max Starets commented on TRINIDAD-1764:
---------------------------------------

Storing component's system event handlers and implementing their state management is extremely similar to dealing with ClientBehaviors. When we implemented storage and state management for ClientBehaviors, we added new ClientBehavior-specific methods to the FacesBean (addClientBehavior(), getClientBehaviors()). Rather than adding new methods on the FacesBean for dealing with SystemEventHandlers, I am proposing to generalize handling of the 'attached' objects in Trinidad components:

- Methods specific to ClientBehaviors should be removed from FacesBean. We probably should not have put them their to begin with, since FacesBean is meant to be used for more than just components.

- A new parametrized AttachedObject class will replace BehvaiorMap.  AttachedObject will be managing both ClientBeahaviors and SystemEventListeners.

- UIXComponentBase will be storing  AttachedObject  instances on the FacesBean as regular properties using indexed PropertyKeys.

- Our PropertyMap implementations do not currently 'descend' into property values for markInitialState() and clearInitialState(). Since attached objects require PartialStateHolder processing, we actually need to process properties representing attached ClientBehaviors and SystemEventListeners. To deal with this case, I added CAP_PARTIAL_STATE_HOLDER capability. Rather then iterate over every property to check for the new capability, I am tracking properties with the CAP_PARTIAL_STATE_HOLDER capability in a bitmask (see the new PropertyTracker class).

Note that the changes to FacesBean will be modifying our API.

> System event listener state saving
> ----------------------------------
>
>                 Key: TRINIDAD-1764
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1764
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 2.0.0-alpha
>            Reporter: Andy Schwartz
>            Assignee: Max Starets
>         Attachments: trinidad-1764.patch
>
>
> The JSF specification requires that UIComponent provide implementations for the following new system event-related methods:
> - subscribeToEvent()
> - unsubscribeFromEvent()
> - getListenersForEventClass()
> Both Mojarra and MyFaces provide implementations of these methods in UIComponent.
> However, UIComponent itself does not provide any state saving implementation.  This is provided by UIComponentBase - ie. UIComponentBase handles state saving for system event listeners stored on the UIComponent instance.
> This approach is flawed in that it only provides correct behavior for component implementations that extend UIComponentBase.  Components that extend UIComponent directly will be subtly broken in that system event listeners can be registered, but will not be state saved.  Furthermore, since the system event listener storage in UIComponent is package-private, there is no way for components that extend UIComponent directly to handle state saving for registered listeners.
> The only option is for components that extend UIComponent directly to implement their own (redundant) storage for system event listeners so that the component implementation can provide its own state saving implementation.
> Since all of the Trinidad components extend UIComponent (not UIComponentBase), we'll need to implement such a solution in UIXComponentBase.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.