To generate the files more dynamically, the file templateFiles.xml can receive some pre-defined values (variables):
We'll see some examples that show how it can be used:

• Generating files with internationalized names:

  <pathGenerationFile>/JavaSource/${bundle.class.name.testMain}.java</pathGenerationFile>

  In the example above, the element pathGererationFile defines the path and name of the file that goes to be generated.
  That is, inside of the JavaSource folder it goes to be generated the file ${bundle.class.name.testMain}.java.
  However as we can see, ${bundle.class.name.testMain} is a variable. It has a prefix 'bundle' that defines that 'class.name.testMain' must be read from the file of resouces from the template (template.properties).

• Generating folders with internationalized names:

  <pathGenerationFile>
     /JavaSource/ide/${bundle.package.mvc.model}/${bundle.package.mvc.model.rules}/TestManager.java
  </pathGenerationFile>

  
  As well as for names of files, the internationalization variable also works for names of folders.
  In the example above, the folder model and rules are internationalized.
  This is necessary to let the template more flexible to different styles of programming and organization. Also on organization to the name and language of the folders and files.

• Customizing the structure of packages of the files:

  <pathGenerationFile>
    /JavaSource/${configSpider.mainPackageDir}/ide/
  ${bundle.package.mvc.model}/${bundle.package.mvc.model.rules}/TestManager.java
  </pathGenerationFile>

  The example above adds a variable to the previous example, where we define folders with internationalized names.
  Now exists also the variable ${configSpider.mainPackageDir}.
  This variable has the prefix 'configSpider', that defines that it must be loaded from the configurations of the project. More specifically from the class org.j2eespider.ide.data.domain.ConfigSpider. This ConfigSpider class, is responsible for storing all the configurations that the user do in the SPIDER to project it.
  In the class ConfigSpider.java exists an attribute mainpackageDir, that is going to be loaded with the variable ${configSpider.mainPackageDir}.
  This attribute defines the main structure of packages of the project. Example: org.j2eespider.project1

• Generating files only if they not exist: In some cases (few cases), is necessary to abort the generation of some file if it already exists.
  Usually the best thing to do is to use the default rule to generate files from SPIDER, that will ask the user if it wants to replace the file, run merge or skip that file.
  But, in default template of SPIDER for example, exists a case, that if the file exist it will not be generated again. We can see this case:

  <templateFile>
  &nbsp; <pathTemplateFile>/tech/generic/build.number</pathTemplateFile>
  &nbsp; <pathGenerationFile>/build.number</pathGenerationFile>
  &nbsp; <skipIfExists>true</skipIfExists>
  </templateFile>

  In this case the generation of the file build.number will be aborted if it already exists. The reason of that is that this file only exists to keep the number of times that the project was built (to create the version number). So there is no reason for the programmer replace this file.
  Then the tag <skipIfExists>true</skipIfExists> must be used in these cases. Where the decision to abort the generation of that file is of template.

• Generating packages without files: One of the functionalities of the SPIDER is to generate the structure of packages of the MVC, even without files.
  This can be done like that:

  <templateFile>
    <pathGenerationFile>
       /JavaSource/${configSpider.mainPackageDir}/${bundle.package.modules}/${configSpider.modulesName}/${bundle.package.mvc.view}
    </pathGenerationFile>
  </templateFile>

  We can see that this templateFile does not have the element. It means that it does not have template, only destinated file (folder). So with this command the packages will be generated in the classpath without files. This is useful to speed the programmer when it want to create a new module in its project. Look thathas some variables. Some from resources file and others are loaded from de projects configs.
  An advanced comment is that ${configSpider.modulesName}
  is not String type and if we check in javadoc, we can see that it is a List<String> type. A project does not only have a module, it can have a list of modules.
  The engine of the SPIDER is already prepared to manage these cases. The <pathGenerationFile> is going to be managed like a list of files to be generated, depending on the length of ${configSpider.modulesName}.