The action registry in the scenarioManager.xml
file contains an optional tag called <action-configuration>
that allows you to configure an action through the .properties
file of a Nucleus component. The following example shows the <action-configuration>
entry for the standard SendEmail
action:
<action-configuration>
/atg/scenario/configuration/SendEmailConfiguration
</action-configuration>
The following example shows the .properties file of the SendEmailConfiguration
component:
# Version: $Change: 244651 $$DateTime: 2002/06/24 09:19:29 $ $class=atg.scenario.action.SendEmailConfiguration defaultEmailInfo=/atg/scenario/DefaultTemplateEmailInfo individualEmailSender=/atg/scenario/IndividualEmailSender collectiveEmailSender=/atg/scenario/CollectiveEmailSender webAppRegistry=/atg/registry/WebApplicationRegistry
The individulaEmailSender
property, for example, allows you to specify the email sender component to use (here, /atg/scenario/IndividualEmailSender
).
If you create a custom action and you want it to be configurable, override the configure
method in your implementation of the atg.process.action.Action
interface to extract the required information from the configuration object that you create. Note that the method must cast the object to the expected type. If you create a custom action and it does not need a flexible configuration, you can omit the <action-configuration>
tag and specify the names and paths of any necessary components directly in the action registry. The configure method, in this case, throws an UnsupportedObjectException
. For more information on this method, refer to the ATG Platform API Reference.
A similar technique exists for configuring scenario conditions. The condition registry in the scenarioManager.xml
file contains an optional tag called <filter-configuration>
that you can use to specify the name and path of a component that contains configuration properties for a scenario condition. The atg.process.filter.ExpressionFilter
class contains a configure
method that you can override to use the settings in the configuration component. Again, the default implementation throws an UnsupportedObjectExpression
so that you can choose to omit the <filter-configuration>
tag if your condition does not need to be configurable through a .properties file.