ChangeManager - The custom identifier should be encapsulated into
ChangeManager, and not in individual Change classes
---------------------------------------------------------------------------------------------------------------------
Key: TRINIDAD-950
URL: https://issues.apache.org/jira/browse/TRINIDAD-950
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.6-core
Reporter: Prakash Udupa N
Here is an API on a Change class whose implementation contains searching
components/nodes while applying the change.
/**
* Constructs a ReorderChange with the given List of identifiers for children.
* @param childIds An in-order collection (List) of Ids (as java.lang.String)
* of child components.
* This List implementation should be of type java.io.Serializable in
* order to be persisted.
* @param identifier Determines the type of identifiers which the List
consists of.
* @throws IllegalArgumentException if supplied childIds were to be null or
supplied
* identifier was to be null or emtpy string.
*/
public ReorderChildrenComponentChange(
List<String> childIds,
String identifier
)
Concept of 'identifier' is a nice feature, it provides for custom identifier
type to be used during lookup of components during the application of change.
The problem with the current API/implementation however is that :
1. This 'identifier' type should be used by the ChangeManager behavior, and is
common to all changes that gets applied by the registered ChangeManager. Hence
it helps to move the 'identifier' parameter out of the various Change classes,
and add it to ChangeManager instead.
2. The implementation to lookup of components matching this 'identifier' is
currently within the Change class. This is better left to ChangeManager. The
ChangeManager could provide utility objects to the ComponentChange and
DocumentChange classes, maybe through the changeComponent() and
changeDocument() methods, and the utility objects could do the lookup.
This proposal :
1. Fixes the design flaw in Trinidad's Change Manager feature, and makes it
better scalable.
2. Custom implementations of ChangeManager can handle the semantics of this
'identifier' and also the nuances of locating components/nodes based on this
semantics, while the Change classes can plug and provide with different
ChangeManagers cleanly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
