In our solution the class is the smallest unit of content that can be aggregated.
These two files are grouped into the “AdfRichPanelStretchLayout” feature. This allows application developers to refer to the af:panelStretchLayout code by the name “AdfRichPanelStretchLayout”, without having to worry about the number, name or locations of files that are used to implement this feature.
Looking at the division of responsibilities, we have:
- Component authors are responsible for grouping these files into logical “features”.
- Application developers are responsible for further grouping these features into larger “partitions”.
<?xml version="1.0" encoding="utf-8"?> <features xmlns="http://xmlns.oracle.com/adf/faces/feature"> <!-- Define the contents of the AdfRichPanelStretchLayout feature --> <feature> <feature-name>AdfRichPanelStretchLayout</feature-name> <!-- This feature contains two classes - the component and the peer --> <feature-class>oracle/adf/view/js/component/rich/layout/AdfRichPanelStretchLayout.js</feature-name> <feature-class>oracle/adfinternal/view/js/laf/dhtml/rich/AdfDhtmlPanelStretchLayoutPeer.js</feature-name> </feature> <!-- Other feature definitions go here --> </features>
Pretty simple really.
The partition configuration is similar, but groups features into partitions:
<?xml version="1.0" encoding="utf-8"?> <partitions xmlns="http://xmlns.oracle.com/adf/faces/partition"> <!-- Define the contents of the "stretch" partition --> <partition> <partition-name>stretch</partition-name> <feature>AdfRichPanelStretchLayout</feature> <feature>AdfRichPanelSplitter</feature> </partition> <!-- Other partition definitions go here --> </partitions>
ADF Faces provides a feature configuration file for its own set of components/framework features and also provides a default partition configuration so that application developers are not required to define a partitioning themselves.