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