[jira] Created: (TRINIDAD-1843) Need to feedback failures for users when a file processor in chain fails
Need to feedback failures for users when a file processor in chain fails Key: TRINIDAD-1843 URL: https://issues.apache.org/jira/browse/TRINIDAD-1843 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0.3-core Reporter: Prakash Udupa N Through JIRA 1757 (https://issues.apache.org/jira/browse/TRINIDAD-1757, we supported chaining of uploaded file processors. There are two means for file upload processors to convey failures. 1. UploadedFileProcessor.processFile() implementations can throw IOException. 2. UploadedFile.getOpaqueData() implementation can convey more information about error. Example of failures could be no space in disk, unacceptable end of line markers, virus etc. Some of these failures need to be notified to users, and currently there is no good mechanism to show this to end users. We log #1, and we do not interpret #2. The File upload happens before the JSF lifecycle kicks in, so we cannot raise faces exceptions or use faces message. This JIRA issue is to track providing some means for the uploaded file processors to be able to propagate failure message to end users. I'm working on a solution and will provide patch soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed
[ https://issues.apache.org/jira/browse/TRINIDAD-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1784: -- Status: Patch Available (was: Open) Session ChangeManager should not apply attribute customizations for cases when it is not needed --- Key: TRINIDAD-1784 URL: https://issues.apache.org/jira/browse/TRINIDAD-1784 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Generic Reporter: Prakash Udupa N Original Estimate: 48h Remaining Estimate: 48h For every request, SessionChangeManager today applies all the attribute based customizations (AttributeComponentChanges) that it gathers in session scope for the view in request. This application happens during tag execution, and just before rendering response, which means that any restored state (due to state saving) and any component binding resolution is all overlayed / masked by the customization applied for the target component. This is undesirable in most of the cases, one simple usecase being: 1. Page A has dynamic number of tabs, and the tab to be disclosed is chosen due to the component binding in every request. Let us assume for this request there were 5 tabs, and tab #1 is the default chosen/disclosed. 2. User is on Page A, selects/discloses tab 3, the tab component wants to treat this gesture as end user personalization and constructs and adds an AttributeComponentChange to set 'disclosed = true' on tab #3. 3. User navigates to Page B, then navigates back to Page A 4. Due to the dynamic nature noted in step #1, the state manager restores the default selection to tab #1, then the component binding decides to add a couple more tabs (now total number of tabs is 7) and also decides that tab #6 should be disclosed, so due to component binding 'disclosed = true' on tab #6 now, and it is false on all other tabs. Now SessionChangeManager during tag execution re-applies the customization and sets the disclosed tab to be tab #3, thereby messing up with what the application intended. Solution: SessionChangeManager should apply attribute changes only in cases where: 1. The request is not a postback 2. We do not have state saved/applied for the view by the JSF state manager implementation. 3. The target component of the change is not a component that was relocated/added earlier due to other types of ComponentChanges (eg. MoveChildComponentChange/AddChildComponentChange) Note that the SessionChangeManager should continue to apply the non-attribute changes (eg. AddChildComponentChange/SetFacetChildComponentChange) regardless of whether it is postback. This is to take care of the situation where JSF runtime tries to normalize the tree structure, and customizations involving structural changes to the component tree applied previously are lost.] This proposal is all implementation fix, and no API changes involved. This solution also leads to performance improvement, given that the attribute based customizations could be very huge due to a lot of user gestures on various interactive components resulting in customizations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed
Session ChangeManager should not apply attribute customizations for cases when it is not needed --- Key: TRINIDAD-1784 URL: https://issues.apache.org/jira/browse/TRINIDAD-1784 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Generic Reporter: Prakash Udupa N For every request, SessionChangeManager today applies all the attribute based customizations (AttributeComponentChanges) that it gathers in session scope for the view in request. This application happens during tag execution, and just before rendering response, which means that any restored state (due to state saving) and any component binding resolution is all overlayed / masked by the customization applied for the target component. This is undesirable in most of the cases, one simple usecase being: 1. Page A has dynamic number of tabs, and the tab to be disclosed is chosen due to the component binding in every request. Let us assume for this request there were 5 tabs, and tab #1 is the default chosen/disclosed. 2. User is on Page A, selects/discloses tab 3, the tab component wants to treat this gesture as end user personalization and constructs and adds an AttributeComponentChange to set 'disclosed = true' on tab #3. 3. User navigates to Page B, then navigates back to Page A 4. Due to the dynamic nature noted in step #1, the state manager restores the default selection to tab #1, then the component binding decides to add a couple more tabs (now total number of tabs is 7) and also decides that tab #6 should be disclosed, so due to component binding 'disclosed = true' on tab #6 now, and it is false on all other tabs. Now SessionChangeManager during tag execution re-applies the customization and sets the disclosed tab to be tab #3, thereby messing up with what the application intended. Solution: SessionChangeManager should apply attribute changes only in cases where: 1. The request is not a postback 2. We do not have state saved/applied for the view by the JSF state manager implementation. 3. The target component of the change is not a component that was relocated/added earlier due to other types of ComponentChanges (eg. MoveChildComponentChange/AddChildComponentChange) Note that the SessionChangeManager should continue to apply the non-attribute changes (eg. AddChildComponentChange/SetFacetChildComponentChange) regardless of whether it is postback. This is to take care of the situation where JSF runtime tries to normalize the tree structure, and customizations involving structural changes to the component tree applied previously are lost.] This proposal is all implementation fix, and no API changes involved. This solution also leads to performance improvement, given that the attribute based customizations could be very huge due to a lot of user gestures on various interactive components resulting in customizations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-1511) Minor bug in the scoped id generator util class - base component being namingcontainer not handled
Minor bug in the scoped id generator util class - base component being namingcontainer not handled -- Key: TRINIDAD-1511 URL: https://issues.apache.org/jira/browse/TRINIDAD-1511 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core, 1.2.12-core Environment: Not applicable Reporter: Prakash Udupa N In class org.apache.myfaces.trinidad.util.ComponentUtils: * @param baseComponent The component relative to which the scoped id for the * targetComponent needs to be determined. * @return The scoped id for target component. Returns null if the supplied * targetComponent was null or did not have an id. */ public static String getScopedIdForComponent( UIComponent targetComponent, UIComponent baseComponent) The above method has a bug that in case the base component happens to be a NamingContainer by itself, the scoped id does not stop with the baseComponent, instead goes up one or more levels to find the NamingContainer. This breaches contract of this method, and breaks ChangeManager functionality in this corner case. The bug is in the private callee _getParentNamingContainer(component, baseComponent), the above case is not handled. Fix involves one line change, will provide the patch soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1511) Minor bug in the scoped id generator util class - base component being namingcontainer not handled
[ https://issues.apache.org/jira/browse/TRINIDAD-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1511: -- Status: Patch Available (was: Open) Minor bug in the scoped id generator util class - base component being namingcontainer not handled -- Key: TRINIDAD-1511 URL: https://issues.apache.org/jira/browse/TRINIDAD-1511 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core, 1.2.12-core Environment: Not applicable Reporter: Prakash Udupa N Original Estimate: 1h Remaining Estimate: 1h In class org.apache.myfaces.trinidad.util.ComponentUtils: * @param baseComponent The component relative to which the scoped id for the * targetComponent needs to be determined. * @return The scoped id for target component. Returns null if the supplied * targetComponent was null or did not have an id. */ public static String getScopedIdForComponent( UIComponent targetComponent, UIComponent baseComponent) The above method has a bug that in case the base component happens to be a NamingContainer by itself, the scoped id does not stop with the baseComponent, instead goes up one or more levels to find the NamingContainer. This breaches contract of this method, and breaks ChangeManager functionality in this corner case. The bug is in the private callee _getParentNamingContainer(component, baseComponent), the above case is not handled. Fix involves one line change, will provide the patch soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1459) Add support for Change Manager (customization) feature for Facelets mode
[ https://issues.apache.org/jira/browse/TRINIDAD-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1459: -- Status: Patch Available (was: Open) Add support for Change Manager (customization) feature for Facelets mode Key: TRINIDAD-1459 URL: https://issues.apache.org/jira/browse/TRINIDAD-1459 Project: MyFaces Trinidad Issue Type: Improvement Components: Facelets Affects Versions: 1.2.12-core Reporter: Prakash Udupa N Original Estimate: 24h Remaining Estimate: 24h Customization/personalization changes stored via the org.apache.myfaces.trinidad.change.SessionChangeManager need to be applied when the view tree is created. This implementation is in the tag handler, and so does not work for Facelets. We need to hook this up right at the point when a stable component/view tree is built and is hanging off view root. We might need to provide a view handler implementation extending the Facelet's view handler, and hook this up. I'll provide a patch soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1284) Facelets Trinidad
[ https://issues.apache.org/jira/browse/TRINIDAD-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703435#action_12703435 ] Prakash Udupa N commented on TRINIDAD-1284: --- The following issue tracks the ChangeManager support in Facelets mode. https://issues.apache.org/jira/browse/TRINIDAD-1459 Facelets Trinidad --- Key: TRINIDAD-1284 URL: https://issues.apache.org/jira/browse/TRINIDAD-1284 Project: MyFaces Trinidad Issue Type: Wish Components: Archetype Affects Versions: 1.0.9-core Environment: Facelets 1.1.14, Trinidad 1.0.9 Reporter: Tomas Havelka I want to ask: Is there a chance, that functionality from UIXComponentTag will be placed anywhere else (for example in UIXComponentBase)? Why am I asking? Facelets dos not using component tags, so functionality implemented in component tags dos not work at all. For example changes manager does not work, because it's called in doEndTag() method of UIXComponentTag which is never called by Facelets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1243) Adding a change implementation to the ChangeManager framework
[ https://issues.apache.org/jira/browse/TRINIDAD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1243: -- Status: Patch Available (was: Open) Adding a change implementation to the ChangeManager framework - Key: TRINIDAD-1243 URL: https://issues.apache.org/jira/browse/TRINIDAD-1243 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.10-core Reporter: Prakash Udupa N Original Estimate: 48h Remaining Estimate: 48h The ChangeManager/ChangePersistence framework in the package 'org.myfaces.trinidad.change' provides different implementations of 'org.myfaces.trinidad.change.ComponentChange' and 'org.myfaces.trinidad.change.DocumentChange'. This feature is quite useful, especially in realizing customizable applications. This framework is lacking a type of Change implementation that allows components to be moved around in the view tree. A strong usecase for this requirement is in a [EMAIL PROTECTED] kind of applications, where users can customize their applications by DragDrop of the components around in a canvas. I propose to introduce an implementation of 'org.myfaces.trinidad.change.ComponentChange' and 'org.myfaces.trinidad.change.DocumentChange', called MoveChildComponentChange. I'll provide a patch soon with this enhancement to Trinidad. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1281) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent()
Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent() --- Key: TRINIDAD-1281 URL: https://issues.apache.org/jira/browse/TRINIDAD-1281 Project: MyFaces Trinidad Issue Type: New Feature Components: Documentation Affects Versions: 1.2.10-core Environment: Not applicable Reporter: Prakash Udupa N Currently JSF RI does not provide any API to generate absolute or scoped id's that can be safely used in calls to UIComponent.findComponent(). This enhancement request is for providing such a utility method in Trinidad. Many frameworks that extend Trinidad could have need for such a utility method as is the case for us. Providing such method in top level framework like Trinidad helps avoid duplicate and/or incorrect implementations around. This method could go in org.apache.myfaces.trinidad.util.ComponentUtils class. I can provide a patch for this soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1281) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent()
[ https://issues.apache.org/jira/browse/TRINIDAD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1281: -- Status: Patch Available (was: Open) Please provide a utility method that can create an absolute/scoped id reverse matching algorithm in UIComponent.findComppnent() --- Key: TRINIDAD-1281 URL: https://issues.apache.org/jira/browse/TRINIDAD-1281 Project: MyFaces Trinidad Issue Type: New Feature Components: Documentation Affects Versions: 1.2.10-core Environment: Not applicable Reporter: Prakash Udupa N Original Estimate: 2h Remaining Estimate: 2h Currently JSF RI does not provide any API to generate absolute or scoped id's that can be safely used in calls to UIComponent.findComponent(). This enhancement request is for providing such a utility method in Trinidad. Many frameworks that extend Trinidad could have need for such a utility method as is the case for us. Providing such method in top level framework like Trinidad helps avoid duplicate and/or incorrect implementations around. This method could go in org.apache.myfaces.trinidad.util.ComponentUtils class. I can provide a patch for this soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1243) Adding a change implementation to the ChangeManager framework
Adding a change implementation to the ChangeManager framework - Key: TRINIDAD-1243 URL: https://issues.apache.org/jira/browse/TRINIDAD-1243 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.10-core Reporter: Prakash Udupa N The ChangeManager/ChangePersistence framework in the package 'org.myfaces.trinidad.change' provides different implementations of 'org.myfaces.trinidad.change.ComponentChange' and 'org.myfaces.trinidad.change.DocumentChange'. This feature is quite useful, especially in realizing customizable applications. This framework is lacking a type of Change implementation that allows components to be moved around in the view tree. A strong usecase for this requirement is in a [EMAIL PROTECTED] kind of applications, where users can customize their applications by DragDrop of the components around in a canvas. I propose to introduce an implementation of 'org.myfaces.trinidad.change.ComponentChange' and 'org.myfaces.trinidad.change.DocumentChange', called MoveChildComponentChange. I'll provide a patch soon with this enhancement to Trinidad. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1229) SetFacetChildDocumentChange adds incomplete facet node to the document
SetFacetChildDocumentChange adds incomplete facet node to the document
--
Key: TRINIDAD-1229
URL: https://issues.apache.org/jira/browse/TRINIDAD-1229
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.9-core
Environment: All environments
Reporter: Prakash Udupa N
The following is the current code in
org.apache.myfaces.trinidad.change.SetFacetChildDocumentChange class:
public void changeDocument(Node componentNode)
{
if (componentNode == null)
throw new IllegalArgumentException(_LOG.getMessage(
NO_NODE_SPECIFIED));
// get the fragement, imported into the target document
DocumentFragment targetFragment =
getImportedComponentFragment(componentNode);
Element facetElement = ChangeUtils.__getFacetElement(componentNode,
_facetName);
if (facetElement != null)
{
// remove any current children
ChangeUtils.__removeAllChildren(facetElement);
}
else
{
Document targetDocument = componentNode.getOwnerDocument();
facetElement = targetDocument.createElementNS(_JSF_CORE_NAMESPACE,
f:facet); // ISSUE IS THAT THIS FACET ELEMENT DOES NOT HAVE 'name' ATTRIBUTE
ON IT
// set the xmlns for the prefix to make sure that f: is the
// prefix for faces
// =-= bts TODO In theory, this could cause problems if the
// added component used the prefix f: for something other than
// the JSF core
facetElement.setAttributeNS(_XMLNS_NAMESPACE, xmlns:f,
_JSF_CORE_NAMESPACE);
componentNode.appendChild(facetElement);
}
// add our new facet content
facetElement.appendChild(targetFragment);
}
When a new SetFacetChildDocumentChange is created and added to the change
manager, and in case the target component did not have a facet already, a new
facet element is created wrapping the supplied document fragment, and added.
The problem, is that the 'name' attribute is added on the element, as indicated
by comments in the code above. This results in parse exceptions by JSP engines.
Fix is to add the 'name' attribute. I'll provide a patch soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1229) SetFacetChildDocumentChange adds incomplete facet node to the document
[
https://issues.apache.org/jira/browse/TRINIDAD-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prakash Udupa N updated TRINIDAD-1229:
--
Status: Patch Available (was: Open)
SetFacetChildDocumentChange adds incomplete facet node to the document
--
Key: TRINIDAD-1229
URL: https://issues.apache.org/jira/browse/TRINIDAD-1229
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.9-core
Environment: All environments
Reporter: Prakash Udupa N
Original Estimate: 2h
Remaining Estimate: 2h
The following is the current code in
org.apache.myfaces.trinidad.change.SetFacetChildDocumentChange class:
public void changeDocument(Node componentNode)
{
if (componentNode == null)
throw new IllegalArgumentException(_LOG.getMessage(
NO_NODE_SPECIFIED));
// get the fragement, imported into the target document
DocumentFragment targetFragment =
getImportedComponentFragment(componentNode);
Element facetElement = ChangeUtils.__getFacetElement(componentNode,
_facetName);
if (facetElement != null)
{
// remove any current children
ChangeUtils.__removeAllChildren(facetElement);
}
else
{
Document targetDocument = componentNode.getOwnerDocument();
facetElement = targetDocument.createElementNS(_JSF_CORE_NAMESPACE,
f:facet); // ISSUE IS THAT THIS FACET ELEMENT DOES NOT HAVE 'name'
ATTRIBUTE ON IT
// set the xmlns for the prefix to make sure that f: is the
// prefix for faces
// =-= bts TODO In theory, this could cause problems if the
// added component used the prefix f: for something other than
// the JSF core
facetElement.setAttributeNS(_XMLNS_NAMESPACE, xmlns:f,
_JSF_CORE_NAMESPACE);
componentNode.appendChild(facetElement);
}
// add our new facet content
facetElement.appendChild(targetFragment);
}
When a new SetFacetChildDocumentChange is created and added to the change
manager, and in case the target component did not have a facet already, a new
facet element is created wrapping the supplied document fragment, and added.
The problem, is that the 'name' attribute is added on the element, as
indicated by comments in the code above. This results in parse exceptions by
JSP engines.
Fix is to add the 'name' attribute. I'll provide a patch soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1229) SetFacetChildDocumentChange adds incomplete facet node to the document
[
https://issues.apache.org/jira/browse/TRINIDAD-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631640#action_12631640
]
pudupa edited comment on TRINIDAD-1229 at 9/16/08 9:01 PM:
This is a patch over 1.2.9.1 branch. The suggested changes is local to one
file, which a.f.a.i.k was unchanged since 1.0 trunk. Hence this patch can be
applied for all branches/trunk wherever this needs to go w.r.t. Apache Myfaces
Trinidad process.
I request that this patch be applied over 1.2.9.1 for immediate consumption.
was (Author: pudupa):
This is a patch over 1.2.9.1 branch. The suggested changes is local to one
file, which a.f.a.i.k was unchanged since 1.0 trunk. Hence this patch can be
applied for all branches/trunk wherever this needs to go w.r.t. Apache Myfaces
Trinidad process.
SetFacetChildDocumentChange adds incomplete facet node to the document
--
Key: TRINIDAD-1229
URL: https://issues.apache.org/jira/browse/TRINIDAD-1229
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.9-core
Environment: All environments
Reporter: Prakash Udupa N
Attachments: TRINIDAD-1229_Patch_On_1_2_9_1.patch
Original Estimate: 2h
Remaining Estimate: 2h
The following is the current code in
org.apache.myfaces.trinidad.change.SetFacetChildDocumentChange class:
public void changeDocument(Node componentNode)
{
if (componentNode == null)
throw new IllegalArgumentException(_LOG.getMessage(
NO_NODE_SPECIFIED));
// get the fragement, imported into the target document
DocumentFragment targetFragment =
getImportedComponentFragment(componentNode);
Element facetElement = ChangeUtils.__getFacetElement(componentNode,
_facetName);
if (facetElement != null)
{
// remove any current children
ChangeUtils.__removeAllChildren(facetElement);
}
else
{
Document targetDocument = componentNode.getOwnerDocument();
facetElement = targetDocument.createElementNS(_JSF_CORE_NAMESPACE,
f:facet); // ISSUE IS THAT THIS FACET ELEMENT DOES NOT HAVE 'name'
ATTRIBUTE ON IT
// set the xmlns for the prefix to make sure that f: is the
// prefix for faces
// =-= bts TODO In theory, this could cause problems if the
// added component used the prefix f: for something other than
// the JSF core
facetElement.setAttributeNS(_XMLNS_NAMESPACE, xmlns:f,
_JSF_CORE_NAMESPACE);
componentNode.appendChild(facetElement);
}
// add our new facet content
facetElement.appendChild(targetFragment);
}
When a new SetFacetChildDocumentChange is created and added to the change
manager, and in case the target component did not have a facet already, a new
facet element is created wrapping the supplied document fragment, and added.
The problem, is that the 'name' attribute is added on the element, as
indicated by comments in the code above. This results in parse exceptions by
JSP engines.
Fix is to add the 'name' attribute. I'll provide a patch soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
[ https://issues.apache.org/jira/browse/TRINIDAD-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa N updated TRINIDAD-1015: -- Status: Patch Available (was: Open) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker - Key: TRINIDAD-1015 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015 Project: MyFaces Trinidad Issue Type: Improvement Environment: Not applicable Reporter: Prakash Udupa N Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose. There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective. Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change: 1. The component that is to be moved. 2. The parent at the destination of the move. 3. The neighboring sibling at the destination to be able to position the component rightly after the move. At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to. During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly. Proposal is to: a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1). b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time. c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
[ https://issues.apache.org/jira/browse/TRINIDAD-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595776#action_12595776 ] pudupa edited comment on TRINIDAD-1015 at 5/9/08 7:01 PM: --- I'd like to see this fix soon, requesting a port of this fix on 1.2.7.1 branch. To make it easier, the attached file ' TRINIDAD-1015-Patch-For-Branch_1.2.7.1-branch.patch' is a patch for the same issue over '1.2.7.1-branch' based off revision #654982. Note to Commiters: 1. Please review both the patches and apply for both the branches the fix if found acceptable. 2. The file (UIXComponentELTag.java) where the relevant change has gone for this patch is not present in the 'trunk', hence the fix is not applicable and not required there. was (Author: pudupa): I'd like to see this fix soon, requesting a port of this fix on 1.2.7.1 branch. To make it easier, the attached file is a patch for the same issue over '1.2.7.1-branch' based off revision #654982. Note to Commiters: 1. Please review both the patches and apply for both the branches the fix if found acceptable. 2. The file (UIXComponentELTag.java) where the relevant change has gone for this patch is not present in the 'trunk', hence the fix is not applicable and not required there. SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker - Key: TRINIDAD-1015 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015 Project: MyFaces Trinidad Issue Type: Improvement Environment: Not applicable Reporter: Prakash Udupa N Attachments: TRINIDAD-1015-Patch-For-Branch_1.2.7.1-branch.patch, TRINIDAD-1015-Patch-For-Branch_trunk_1.2.x.patch Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose. There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective. Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change: 1. The component that is to be moved. 2. The parent at the destination of the move. 3. The neighboring sibling at the destination to be able to position the component rightly after the move. At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to. During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly. Proposal is to: a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1). b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time. c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
[ https://issues.apache.org/jira/browse/TRINIDAD-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595774#action_12595774 ] pudupa edited comment on TRINIDAD-1015 at 5/9/08 7:01 PM: --- The attached file ' TRINIDAD-1015-Patch-For-Branch_trunk_1.2.x.patch ' is the patch for this Jira issue on trunk_1.2.x based off revision #654993. was (Author: pudupa): This is the patch for this Jira issue on trunk_1.2.x based off revision #654993. SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker - Key: TRINIDAD-1015 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015 Project: MyFaces Trinidad Issue Type: Improvement Environment: Not applicable Reporter: Prakash Udupa N Attachments: TRINIDAD-1015-Patch-For-Branch_1.2.7.1-branch.patch, TRINIDAD-1015-Patch-For-Branch_trunk_1.2.x.patch Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose. There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective. Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change: 1. The component that is to be moved. 2. The parent at the destination of the move. 3. The neighboring sibling at the destination to be able to position the component rightly after the move. At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to. During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly. Proposal is to: a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1). b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time. c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker - Key: TRINIDAD-1015 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015 Project: MyFaces Trinidad Issue Type: Improvement Environment: Not applicable Reporter: Prakash Udupa N Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose. There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective. Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change: 1. The component that is to be moved. 2. The parent at the destination of the move. 3. The neighboring sibling at the destination to be able to position the component rightly after the move. At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to. During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly. Proposal is to: a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1). b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time. c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-950) ChangeManager - The custom identifier should be encapsulated into ChangeManager, and not in individual Change classes
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( ListString 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.
