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.