ADF Naming Conventions – Part III

Hi all and welcome to another blog post on ADF Naming Conventions.

In my previous post ADF Naming Conventions – Part II I have focused my attention on:

• Model & View Controller Project

Today I will focus on:

• Task Flows
• Templates
• JSF, JSFF, JSPX
• JAVA Events
• JAR, WAR, EAR files

In this section, we will provide the namings related with task flows.

Task Flow Naming

The name for Task Flows should be defined as follows:

<TASK_FLOW_CAMEL_CASE> + TF

Example: myTaskFlowTF

We may have different task flows types, each one built to address one purpose. For these cases we added a constant to the name to easily recognize their purpose/target. The table below lists the Types and Target Names:

Task Flow Managed Beans

Task Flows’ managed beans are responsible for managing data. Multiple managed beans can be created for a single Task Flow. Nevertheless, you usually have one main managed bean. For these cases, managed beans should have a name similar to the task flow.

As you may have already noticed, you are free to provide any name you want to the Java Class you assign to your managed bean in “Managed Beans” task flow’s tab. For this scenario, we recommend to use the same name of the Java Class.

By following this two advises you will be able to more easily find what you are looking for  without losing time and effort to understand the mappings made by each developer. This is very important for developers during development and maintenance phases. Based on these assumptions take a look at the following example:

Task Flow Input & Return Parameters

Task flow’s input parameters should be prefixed with “in”:

in + <CAMEL_CASE>

Example: inMyParameter

Task flow’s return parameters should be prefixed with “rtn”:

rtn + <CAMEL_CASE>

Example: rtnMyParameter

ADF let us create different types of templates to abstract common functionalities used in our projects, for example Page Templates and Task Flow Templates. These templates should be created using the following pattern:

<CAMEL_CASE> + Template

Example: myTaskFlowTemplate, myPageTemplate

Pages names should have a self-explanatory name to be easily identified and recognized for its purpose. The default pattern we followed was:

<CAMEL_CASE>

In Task Flows you may have multiple pages depending on the route it takes, but for the main page (if we have one) we should provide it with the same name as the task flow but without ‘TF’ suffix.

Example:

We set suffixes for our control events. This will help you to understand the event type you are taking care without the need to go directly to the page, only if you need to understand it in more detail. The suffixes for each type of event are listed in the following table:

Building and deploying projects lead us to create deployment profiles. In these deployments profiles, the same naming should be used. The next table addresses this topic by providing the naming for each type of deployment profile.

You can find the PDF with these series of posts right here.

I hope these series of posts may help you in your projects 🙂

Cheers,

Pedro Gabriel

@PedrohnGabriel