myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Starets (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TRINIDAD-1764) System event listener state saving
Date Wed, 08 Dec 2010 22:02:02 GMT

    [ 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.


Mime
View raw message