[jira] [Created] (TRINIDAD-2239) Improve the ancestor based change filtering mechanism by introducing a formal ComponentChangeFilter
Improve the ancestor based change filtering mechanism by introducing a formal
ComponentChangeFilter
---
Key: TRINIDAD-2239
URL: https://issues.apache.org/jira/browse/TRINIDAD-2239
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
TRINIDAD-2221 provided mechanism for ancestors to decide if ComponentChange
targeting one of its descendants should be added to ChangeManager.
This one is asking for further improvement to this mechanism, by formalizing
the contract more. Proposal is to add the following API:
1. An abstract class 'org.apache.myfaces.trinidad.change.ComponentChangeFilter'
that clients / listeners can implement specializations to accept / reject
certain changes on certain components, and then add to the components.
public abstract class ComponentChangeFilter
{
public abstract Result accept(ComponentChange componentChange, UIComponent
changeTargetComponent);
public enum Result
{
ACCEPT,
REJECT
}
}
2. An abstract implementation
'org.apache.myfaces.trinidad.change.ComponentReferencingComponentChangeFilter'
to solve usecases where such a filter needs to hold component reference.
One such usecase is where ComponentChanges belonging to certain component
subtree is rejected, by keeping a reference to the subtree root component. We
leverage on 'org.apache.myfaces.trinidad.util.ComponentReference' for this
implementation.
3. The following methods on UIXComponentBase to be able to attach / detach
ComponentChangeFilters to the components:
public final void addComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
public final void removeComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
Implementation:
In implementation of UIXComponentBase.addComponentChange(UIComponent component,
ComponentChange change), we will not add a ComponentChange if any of the
ComponentChangeFilters that is attached to the target component itself or any
of its ancestors rejects the ComponentChange.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2226) Provide mechanism to reload skin definitions from trinidad-skins.xml
Provide mechanism to reload skin definitions from trinidad-skins.xml
Key: TRINIDAD-2226
URL: https://issues.apache.org/jira/browse/TRINIDAD-2226
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
Currently there is no way to be able to update the skins to an app at runtime
without needing to restart the app. Request here is to provide it in Trinidad's
skinning framework.
Requirement: Provide an API that complies to the following:
-
1. Reads (or marks it dirty so that it is read in next request)
trinidad-skins.xml and update the new skin definitions as per its contents
2. Subsequent requests on the webapp should reflect the skin definitions from
trinidad-skins.xml that was re-read
3. Should be statically called (because the clients of such API are usually
deployment tools that work outside of JSF lifecycle)
4. Cannot depend on any context object other than ServletContext (because that
is what a non-JSF entry point to this API can provide)
Proposed API:
-
1. New public non-static method in
'org.apache.myfaces.trinidad.skin.SkinFactory'
/**
* Reloads the skins that was registered with this factory.
* Subclassers are expected to provide the implementation.
*/
public void reload()
- We implement this in
'org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl'. In this
implementation we will preserve the order in which we register skins, which is
the following:
a) Register the base skins in Trinidad
b) Give chance to all registered Configurator services to attach their
skins to the SkinFactory programatically.
c) Read trinidad-skins.xml from META-INF and WEB-INF, and for the skin
definitions in there, create Skins and register with the SkinFactory
- Clients will call 'SkinFactory.getFactory().reload();' after updating the
trinidad-skins.xml to be able to reload the skins in the next request to the
app (browser cache clearance / Ctrl+F5 is of course needed).
2. New public method in 'org.apache.myfaces.trinidad.config.Configurator'
/**
* The skinning framework calls this method to notify Configurators that the
specified SkinFactory has been reloaded.
* The Configurator implementations may choose to reload skins here.
* @param externalContext the external context
* @param factory the SkinFactory instance to which the skins can be reloaded
*/
public void reloadSkins(ExternalContext externalContext, SkinFactory factory){}
- This method will be no-op in the Configurator class, and can optionally be
implemented by any registered configurator services.
- The reload() method noted in #1 above will call this method on all registered
configurator services before attempting to register the skins from
trinidad-skins.xml that it will re-read now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2209) Provide ChangeManager APIs to remove and restore changes to components in a subtree
Provide ChangeManager APIs to remove and restore changes to components in a subtree --- Key: TRINIDAD-2209 URL: https://issues.apache.org/jira/browse/TRINIDAD-2209 Project: MyFaces Trinidad Issue Type: Improvement Components: Components, Infrastructure Affects Versions: 2.0.2-core Environment: n/a Reporter: Prakash Udupa There are frequent changes to attributes of components due to end user interaction. For example the 'displayIndex' value of a custom 'column' component changes whenever user reorders the column in a table. SessionChangeManager records such changes on certain attributes of certain components and restores it as 'preference' / 'personalization' for that user for future 'GET' requests on the page. While this is generally desirable, it sometimes could interfere with expectations of other components. For example a custom 'query' component may choose to allow users to save keyed by a 'name' the 'search criteria', and then additionally the 'layout' of the results area, which most likely is a table. The changes on the table (or any other component on results area) that the SessionChangeManager frequently saves and restores interferes with the component's feature to save and restore the layout of the results area / table. We need some ChangeManager API to reduce this interference. This proposal is to add APIs to ChangeManager that components can call to: 1. Remove the ChangeManager changes for the result area subtree when it switches to a saved search that includes layout. 2. Add back the ChangeManager changes for the result area subtree when user switches to a saved search that does not include a layout. Specifically proposing the following new APIs (two public methods) on ChangeManager class: /** * Removes all changes that the ChangeManager holds for components in a subtree. * Note that the ChangeManager would still continue to record any new changes on the * components in the subtree. * @param subTreeRoot The UIComponent that is the root of the component subtree for which the *changes are to be removed. Note that if the viewroot is suplied, the *changes for the entire view are removed. * @return Object a Serializable Object of all the component changes for the subtree that was *just removed. This value can be passed back to *restoreComponentChangesForSubtree() to restore the changes. */ public Object removeComponentChangesForSubtree(FacesContext context, UIComponent subTreeRoot) /** * Restores the component changes to the ChangeManager for components in a subtree. * Before adding the changes, if there are existing changes to the subtree it will be removed. * @param changes The Serializable Object of the component changes as returned by *removeComponentChangesForSubtree() */ public void restoreComponentChangesForSubtree(FacesContext context, Object changes) These methods will be implemented in SessionChangeManager, and will be a no-op in the document based ChangeManager implementations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2155) Incomplete serialization implementation in AccessibilityProfile$SerializableAccessibilityProfile
Incomplete serialization implementation in
AccessibilityProfile$SerializableAccessibilityProfile
Key: TRINIDAD-2155
URL: https://issues.apache.org/jira/browse/TRINIDAD-2155
Project: MyFaces Trinidad
Issue Type: Bug
Components: Archetype
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
Issue:
Regarding the serializable inner class of AccessibilityProfile...
private static final class SerializableAccessibilityProfile extends
AccessibilityProfile implements Serializable
The super class no-arg constructor has private access, this will lead to the
following error...
Exception in thread main java.io.InvalidClassException:
org.apache.myfaces.trinidad.context.AccessibilityProfile$SerializableAccessibilityProfile;
org.apache.myfaces.trinidad.context.AccessibilityProfile$SerializableAccessibilityProfile;
no valid constructor
at
java.io.ObjectStreamClass.checkDeserialize(ObjectStreamClass.java:713)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1733)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at client.AccSerialTest.main(AccSerialTest.java:22)
Caused by: java.io.InvalidClassException:
org.apache.myfaces.trinidad.context.AccessibilityProfile$SerializableAccessibilityProfile;
no valid constructor
at java.io.ObjectStreamClass.init(ObjectStreamClass.java:471)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at client.AccSerialTest.main(AccSerialTest.java:19)
Testcase:
--
package client;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import org.apache.myfaces.trinidad.context.AccessibilityProfile;
public class AccSerialTest
{
public static void main(String[] args)
throws Exception
{
System.out.println(SERIALIZING);
AccessibilityProfile acc = AccessibilityProfile.getDefaultInstance();
ObjectOutputStream os = new ObjectOutputStream(new
FileOutputStream(c:\\Temp\\serial.txt));
os.writeObject(acc);
System.out.println(DE-SERIALIZING);
ObjectInputStream is = new ObjectInputStream(new
FileInputStream(c:\\Temp\\serial.txt));
is.readObject();
}
}
Fix:
-
Make the constructor protected. Patch attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
