Procedure – Configuring Table Common Component
Creating a new Builder class
A table builder class corresponds to a table configuration. All the table-level as well as column-level properties should be configured in the builder class. When creating a new builder class, you should typically extend one of the abstract base classes provided by the MVC infrastructure:
• AbstractConfigurableTableBuilder
Use this base class if you are implementating a tree or table that supports configurable table views. This base class is located in the CoreHtmlComp module due to its dependency on the configurable table infrastructure.
• AbstractComponentBuilder
Use this base class for tables and trees that do not support configurable tables
• AbstractComponentConfigBuilder
Use this base class for info pages. You can also use this if you wish to separate your table or tree config builder from its data builder (not a typical use case).
• AbstractComponentDataBuilder
Use this base class for table and tree implementations where you have chosen to separate the config and data builder implementations (not a typical use case).
Implementing the ComponentConfigBuilder API
The table and column level configuration options can be specified by implementing ComponentConfigBuilder. ComponentConfigBuilder currently defines one method:
ComponentConfig buildComponentConfig(ComponentParams params);
The responsibility of this method roughly corresponds to what the describeTable tag does in 9.x versions.
The ComponentConfig hierarchy:
Using ComponentConfigFactory to get Table/column ComponentConfig objects
It is not necessary to create a ComponentConfig directly, instead use a ComponentConfigFactory. When extending the abstract base builder classes, the factory is available by calling getComponentConfigFactory(). When directly implementing ComponentConfigBuilder, also implement ComponentConfigFactoryAware. This will get you a reference to the factory when the builder is initialized.
Instance of TableConfig and ColumnConfig need to be used to specify table level and columns level customizations respectively. An example to get the TableConfig/ColumnConfig instance look like this:
ComponentConfigFactory factory = getComponentConfigFactory();
TableConfig table = factory.newTableConfig();
…
ColumnConfig col1 = factory.newColumnConfig(“column1Id”, false);
…
table.addComponent(col1);
Since column component is a nested component of table component, ColumnConfig can be added to the TableConfig using the addComponent() API as shown in above code snippet.
Setting properties on TableConfig and ColumnConfig:
Customization points available for the config classes are described in
Customization Points. Refer to the JavaDoc for more details on the properties and capabilities of each config class.
Localizing your configs
To localize values within your config builder, the Mvc infrastructure provides a new ClientMessageSource class. If you are extending one of the abstract configuration base classes, then you can call getMessageSource(String) to create a message source for a given resource bundle class name. ClientMessageSource works like WTMessage, but ensures that the locale that you use is the client locale, rather than the locale that the server is running with.
Specifying the view JSP
Implementing the ComponentDataBuilder API
The data acquisition mechanism for table can be configured using ComponentDataBuilder interface. The data builder class needs to implement ComponentDataBuilder interface. ComponentDataBuilder currently defines one method:
Object buildComponentData(ComponentConfig config, ComponentParams params)
The responsibility of this method roughly corresponds to what the getModel/getIeModel tag do in JCA in the 9.x release stream.
Registering your ConfigurableTable
If your ComponentConfigBuilder implementation also implements ConfigurableTableBuilder, then you do not need to register your ConfigurableTable implementation in service.properties. You cannot register ConfigurableTableBuilder implementations themselves, independent from a ComponentConfigBuilder implementation.
Implementing your ConfigurableTable
You may choose to implement your ConfigurableTable as a static inner class of your builder, or to put it in a separate file. If you only intend to use it from within the builder implementation, then we recommend defining it as a private static inner class. An example:
public class MyTableBuilder extends AbstractConfigurableTableBuilder {
…
@Override
public ConfigurableTable buildConfigurableTable(String tableId) throws WTException {
return new MyConfigurableTable();
}
private static class MyConfigurableTable extends JCAConfigurableTable {
…
}
…
}
Configuring separate config and data builders
If you wish to implement your config and data builders in separate classes, then you must supply an additional ComponentBuilderType parameter to the @ComponentBuilder annotation.
For config builders, this looks like:
@ComponentBuilder(value=“my.component.id”,
type=ComponentBuilderType.CONFIG)
public class MyConfigBuilder implements ComponentConfigBuilder…
For data builders, this looks like:
@ComponentBuilder(value=“my.component.id”,
type=ComponentBuilderType.DATA)
public class MyDataBuilder implements ComponentDataBuilder…
If you wish to configure separate builders without using annotations, then the bean ids you choose must have the “.configBuilder” or “.dataBuilder” suffix. For example to configure a config builder, you would do the following:
<bean name=”myComponent.configBuilder”
class=”my.config.builder.class.name”/>
Registering MVC builders
MVC builders can be registered using ComponentBuilder annotation or via explicit configuration, or by automated scanning. Automated scanning. After registering the table builders, the table component can be configured into the application in actions.xml just as JSP-based JCA components.
See
MVC Components and
Constructing and Rendering a Table Using the JSP Framework for more information on registering/configuring the table component.
