The Java template file

• <component_name>_begin.javajet
• <component_name>_main.javajet
• <component_name>_end.javajet

For more information regarding the component code generation model, see Component code generation model.

JET is a "model to text" engine which allows you to generate (text) output based on an EMF model. For example you can generate SQL, Java, XML, Text, HTML, etc. JET uses a template technology which is very closely related to the syntax of Java Server Pages (JSP).

In Talend Studio, the template files are translated to Java code. A template file contains two different types of Java code: the template code and the Java output code. The template code is included in <% %> tags. As for JSP pages, on the top part of the templates file, the required classes are imported. They can vary according to your needs. However, there are some default ones we usually add to each javajet template file.

<%@ jet
    imports="
        org.talend.core.model.process.INode
        org.talend.core.model.process.ElementParameterParser
        org.talend.core.model.metadata.IMetadataTable
        org.talend.core.model.metadata.IMetadataColumn
        org.talend.core.model.process.IConnection
        org.talend.core.model.process.IConnectionCategory
        org.talend.designer.codegen.config.CodeGeneratorArgument
        org.talend.core.model.metadata.types.JavaTypesManager
        org.talend.core.model.metadata.types.JavaType
        java.util.List
        java.util.Map      
    "
%>

This is a particular section of the JET template: the JET imports section. You will need it in all the template files since they are compiled separately. The classes listed in the import section are Talend specific.

Below are the lines present in each javajet templates file after the JET import section.

<%
    CodeGeneratorArgument codeGenArgument = (CodeGeneratorArgument) argument;
    INode node = (INode)codeGenArgument.getArgument();
    String cid = node.getUniqueName(); 
%>

These codes are used to retrieve the values of defined properties of the component and get the unique name of the component. Each component in a Job is a Node whose interface is INode. cid is the component identifier and it is a unique name.

Logically, a component can be used many times in a Job and you cannot predict the name of the variables used in the other components or even how many times the same component will be used, how they are interconnected etc. Talend provides a safe way to make variable unique: adding the unique name of the component as a suffix to each variable declared in the template file. For example:

int nb_line_<%=cid %> = 0;

tFileInputDelimited_1 is the unique name of the tFileInputDelimited component in the Job below:

This line is translated to the Java code as below in the Job generated code:

int nb_line_tFileInputDelimited_1 = 0;

Here is a piece code of a template file:

<%
public void useShareConnection(INode node) {
    String sharedConnectionName = ElementParameterParser.getValue(node, "__SHARED_CONNECTION_NAME__");
%>
    String sharedConnectionName_<%=cid%> = <%=sharedConnectionName%>;
    conn_<%=cid%> = SharedDBConnection.getDBConnection("<%=this.getDirverClassName(node)%>",url_<%=cid%>,userName_<%=cid%> , password_<%=cid%> , sharedConnectionName_<%=cid%>);
<%
}
%>

The template code is included between <% %> tags, and the Java output code, that will really be present in the Job generated code and be executed, is not surrounded by <% %> tags. In this case, the following two lines are the Java output code:

String sharedConnectionName_<%=cid%> = <%=sharedConnectionName%>;
conn_<%=cid%> = SharedDBConnection.getDBConnection("<%=this.getDirverClassName(node)%>",url_<%=cid%>,userName_<%=cid%> , password_<%=cid%> , sharedConnectionName_<%=cid%>);

At the end of the template, we have to close the opened blocks:

<%
}
%>