Development Guide

In this section, practical development steps are discussed for anyone interested in contributing to the VLINGO XOOM Designer project.

Features

The XOOM Designer codebase mainly contains the implementation of the following features:

  • XOOM Designer: the visual model designer itself that, besides the project generation, provides a rapid configuration for VLINGO XOOM components.

  • XOOM CLI: provides shortcuts for initializing XOOM Designer and interacting with Docker, Gloo Gateway API, and Kubernetes;

Although sharing the same codebase, these two features are not strongly dependent, so it's meant to be kept semantically and structurally separate. In that sense, the Designer and CLI implementations are respectively placed under the package io.vlingo.xoom.designer and io.vlingo.xoom.cli.

Next, the practical sections show how to maintain and expand both features.

Introduction to CLI

Once the XOOM Designer is correctly installed, the CLI is accessed from the terminal by calling the executable bash script (ex. ./xoom docker package). Internally, this script runs the Designer jar and passes the command, i.e. docker package, to the CommandLineInterfaceInitializer class:

public class CommandLineInterfaceInitializer { 

  public static void main(final String[] args) {  
      ...
      
      final Task task = Task.triggeredBy(resolveCommand(args));      
      
      runTask(task, Arrays.asList(args));  
  }
 
  ...
}

The code snippet above shows that an implementation of io.vlingo.xoom.cli.task.Task is triggered by the user command, implying that there is one Task subclass for each supported task. Next, the task implementation responsible for initializing the Designer service is demonstrated:

public class DesignerTask extends Task {  
    
    private final DesignerInitializer initializer;  
    
    ...
    
    @Override  
    public void run(final List<String> args) {    
        this.initializer.start(OptionValue.mapValues(options, args));  
    }

}

The OptionValue class helps tasks to support execution options, which are passed along with the bash command. For instance, the designer server port can be customized as follows: 

$ ./xoom designer --port 8081

The concluding step of a Task implementation is to edit the ComponentRegistration class mapping the task as an element of the cliTasks list. That makes XOOM CLI able to run the task when the corresponding command is executed:


public class ComponentsRegistration {

  public static void registerWith(final Logger logger,
                                  final CommandExecutionProcess commandExecutionProcess,
                                  final XoomTurboProperties properties) {
    ComponentRegistry.register("cliTasks", Arrays.asList(new DesignerTask(commandExecutionProcess),  new DockerPackageTask(commandExecutionProcess) ...);
}

Introduction to Designer

The following diagram gives us an overview of how the Designer components interact for generating a project:

The Designer-embedded user interface illustrated above is built with Svelte. It consumes a Rest API submitting the model details to the server-side. Once successfully processed, XOOM Designer uses Apache FreeMarker for generating classes, configuration, and deployment files. That said, let's see how to add templates at the code level.

For any development on XOOM Designer you must set an environment variable named VLINGO_XOOM_STARTER_HOME. Although you have likely already set this property in order to use the XOOM Designer, that was as an enduser, which has a different value. As a developer working on the Designer, you must set this to the absolute path of a directory relative to where the vlingo-xoom-starter repository has been cloned.

Using a *nix shell, such as bash, set like this:

$ VLINGO_XOOM_DESIGNER_HOME=[git-clone-path]/dist/designer
$ export VLINGO_XOOM_DESIGNER_HOME

On Windows you can use the System Properties > Advanced > Environment Variables... to set the property permanently. For a one-time setting before running the design tool you can use the command line:

C:\> set VLINGO_XOOM_DESIGNER_HOME=[git-clone-path]\dist\designer

After making changes, from the root project directory, build and run the Designer. On *nix run these commands:

$ mvn clean package -P frontend
...
$ java -jar target/xoom-designer-1.6.1-SNAPSHOT.jar gui

This works on Windows:

C:\[git-clone-path]> mvn clean package -P frontend
...
C:\[git-clone-path]> java -jar target\xoom-designer-1.6.1-SNAPSHOT.jar gui

For more details see README.md in the xoom-designer repository.

Model Processing Steps

While the previous section provides a quick introduction to the Designer components, this section focuses on explaining each step involved in the Designer Model processing, going through the layers, from the external to the inner, API to the full project generation.

First, let's consider how the web-based UI interacts with the Rest API when the project generation is requested:

The figure above shows the two requests submitted when the user finishes the Designer model and clicks the generate button. The first request checks if the generation path is valid by creating the full directory tree where the generated project is going to be installed. If it succeeds, the project generation is subsequently requested. The handler methods responsible for processing these requests are presented below: 

package io.vlingo.xoom.designer.infrastructure.restapi;

public class ModelProcessingResource extends DynamicResourceHandler {

  private final ModelProcessingManager modelProcessingManager;
  
  ...

  public Completes<Response> startGeneration(final DesignerModel model) {
    return modelProcessingManager.generate(model, modelProcessingInformation, logger).andThenTo(scene -> {
              final Response.Status responseStatus = scene.isFailed() ? InternalServerError : Ok;
              return Completes.withSuccess(Response.of(responseStatus, serialized(scene.report)));
            });
  }
  
  public Completes<Response> makeGenerationPath(final GenerationPath path) {
    try {
      modelProcessingManager.createGenerationPath(new File(path.path));
      return Completes.withSuccess(Response.of(Created, headers(of(Location, path.path)), path.serialized()));
    } catch (final GenerationPathAlreadyExistsException e) {
      return Completes.withSuccess(Response.of(Conflict, path.serialized()));
    } catch (final GenerationPathCreationException e) {
      return Completes.withSuccess(Response.of(Forbidden, path.serialized()));
    }
  }
  
  ...
}

ModelProcessingResource depends on ModelProcessingManager for making the generation path and generating the project. Let's get deeper into the code and see how ModelProcessingManager implements the project generation.

public class ModelProcessingManager {

  private final List<CodeGenerationStep> codeGenerationSteps = new ArrayList<>();

  public ModelProcessingManager(final List<CodeGenerationStep> codeGenerationSteps) {
    this.codeGenerationSteps.addAll(codeGenerationSteps);
  }

  public Completes<ModelProcessingScene> generate(final DesignerModel model,
                                                  final ModelProcessingInformation information,
                                                  final Logger logger) {
    return validate(model, information)
            .andThenTo(scene -> mapContext(scene, logger))
            .andThen(scene -> processSteps(scene));
  }
  
  private Completes<ModelProcessingScene> validate(final DesignerModel model,
                                                   final ModelProcessingInformation information) {
    final ModelProcessingScene scene = ModelProcessingScene.with(model, information);
    final String validationErrors = String.join(", ", model.validate());
    if(validationErrors.isEmpty()) {
      return Completes.withSuccess(scene);
    }
    return Completes.withFailure(scene.onValidationFail(validationErrors));
  }

  private Completes<ModelProcessingScene> mapContext(final ModelProcessingScene scene,
                                                     final Logger logger) {
    try {
      final CodeGenerationContext codeGenerationContext =
              CodeGenerationContextMapper.map(scene.designerModel,
                      scene.information.generationTarget, logger);

      return Completes.withSuccess(scene.addCodeGenerationContext(codeGenerationContext));
    } catch (final Exception exception) {
      exception.printStackTrace();
      return Completes.withFailure(scene.onContextMappingFail(exception));
    }
  }

  private ModelProcessingScene processSteps(final ModelProcessingScene scene) {
    try {
      codeGenerationSteps.stream()
              .filter(step -> step.shouldProcess(scene.codeGenerationContext))
              .forEach(step -> step.process(scene.codeGenerationContext));

      return scene.onCodeGenerationSucceed();
    } catch (final Exception exception) {
      ...
    }
  }

Reading the ModelProcessingManager code from the top, it's clear that its constructor receives a CodeGenerationStep list. The details of this ModelProcessingManager dependency are explained later, but, for now, just keep in mind that the list elements are every step responsible for creating or customizing a piece of the generated project such as configuration files, source code, and other resources.

The ModelProcessingManager.generate is the high-level method for the project generation. It uses some auxiliary methods in order to keep the code more organized and readable. Here are the competencies of each one of these auxiliary methods:

That said, let's have a look at the elements of the CodeGenerationStep list declared in io.vlingo.xoom.designer.Configuration:

public class Configuration {
  
  ...
  
  private static List<CodeGenerationStep> codeGenerationSteps() {
    return Arrays.asList(
            //Preliminary
            new CodeGenerationParameterValidationStep(),
            new MainClassResolverStep(),
            new StagingFolderCleanUpStep(Phase.PRE_GENERATION),
            new TemporaryTaskFolderCreationStep(),
            //Java
            new ReadmeFileGenerationStep(),
            new ApplicationSettingsGenerationStep(),
            new ValueObjectGenerationStep(),
            new ModelGenerationStep(),
            new DataObjectGenerationStep(),
            new ProjectionGenerationStep(),
            new StorageGenerationStep(),
            new RestResourceGenerationStep(),
            new AutoDispatchMappingGenerationStep(),
            new ExchangeGenerationStep(),
            new SchemataGenerationStep(),
            new BootstrapGenerationStep(),
            new EntityUnitTestGenerationStep(),
            new QueriesUnitTestGenerationStep(),
            new ProjectionUnitTestGenerationStep(),
            new RestResourceAbstractUnitTestGenerationStep(),
            new RestResourceUnitTestGenerationStep(),
            new ClusterSettingsGenerationStep(),
            new DesignerModelGenerationStep(),
            new DockerfileGenerationStep(),
            new KubernetesManifestFileGenerationStep(),
            //React
            new StaticFilesGenerationStep(),
            new LayoutGenerationStep(),
            new AggregateManagementGenerationStep(),
            //Concluding
            new ContentCreationStep(),
            new MavenWrapperInstallationStep(),
            new SchemaPushStep(...),
            new SchemaPullStep(...),
            new StagingFolderCleanUpStep(Phase.POST_GENERATION)
    );
  }

}

The steps are grouped either by the generation phase or the programming language/technology on which a specific project part is generated. The preliminary steps are responsible for preparing the internal Designer resources for a new project generation and also defining TemplateParameter values to be used in the later steps.

The core steps, declared between the preliminary and concluding steps, extend TemplateProcessingStep which is a subclass of CodeGenerationStep. This extension allows these steps to easily process Freemarker templates based on Java/React technologies.

At last, the concluding steps, like the preliminary steps, are simple CodeGenerationStep extensions that respectively perform the following tasks:

  • Physically create the template output processed in the core steps;

  • Copy necessary resources to the generated project;

  • Executes Maven-based Schemata goals;

  • Clear leftovers of the generated project from Designer internals;

The next section discusses how to implement a CodeGenerationStep and create/update code templates.

Create / Update Code Templates

The main constituent parts for every auto-generated class / project resouce are:

Considering those parts, let's take AggregateProtocol class generation as an example and go through the implementation details, starting from the template file:

package ${packageName};

<#if imports?has_content>
<#list imports as import>
import ${import.qualifiedClassName};
</#list>
</#if>

public interface ${aggregateProtocolName} {
  <#if !useCQRS>

  /*
   * Returns my current state.
   *
   * @return {@code Completes<${stateName}>}
   */
  Completes<${stateName}> currentState();
  </#if>

}

The Aggregate Protocol template file requires some parameter values to generate an Aggregate Protocol class. The parameters handling and mapping are addressed by AggregateProtocolTemplateData as follows:

public class AggregateProtocolTemplateData extends TemplateData {

  private final String protocolName;
  private final TemplateParameters parameters;

  public AggregateProtocolTemplateData(final String packageName,
                                       final CodeGenerationParameter aggregate,
                                       final List<Content> contents,
                                       final Boolean useCQRS) {
    this.protocolName = aggregate.value;
    this.parameters = TemplateParameters.with(TemplateParameter.PACKAGE_NAME, packageName)
            .addImports(resolveImports(aggregate, contents))
            .and(TemplateParameter.AGGREGATE_PROTOCOL_NAME, aggregate.value)
            .and(TemplateParameter.STATE_NAME, JavaTemplateStandard.AGGREGATE_STATE.resolveClassname(aggregate.value))
            .and(TemplateParameter.USE_CQRS, useCQRS);
  }

  private Set<String> resolveImports(final CodeGenerationParameter aggregate, final List<Content> contents) {
    return ValueObjectDetail.resolveImports(contents, aggregate.retrieveAllRelated(Label.STATE_FIELD));
  }

  @Override
  public String filename() {
    return standard().resolveFilename(protocolName, parameters);
  }

  @Override
  public TemplateParameters parameters() {
    return parameters;
  }

  @Override
  public TemplateStandard standard() {
    return JavaTemplateStandard.AGGREGATE_PROTOCOL;
  }

}

The full package name and the AggregateProtocol class name are mapped to the template parameters in loadParameters. Additionally, TemplateData requires the filename method implementation, which commonly uses the filename resolution logic in the corresponding TemplateStandard.

public class ModelGenerationStep extends TemplateProcessingStep {

  @Override
  protected List<TemplateData> buildTemplatesData(final CodeGenerationContext context) {
    return ModelTemplateDataFactory.from(context);
  }

  @Override
  public boolean shouldProcess(final CodeGenerationContext context) {
    return context.hasParameter(Label.AGGREGATE);
  }

}

ModelGenerationStep implements the buildTemplateData method that passes parameter values, coming from the Web-based UI, to RestResourceTemplateData. In this particular scenario, ModelTemplateDataFactory is an additional and optional class that helps building AggregateProtocolTemplateData. The shouldProcess method is also optional and useful when a TemplateProcessingStep subclass needs to be conditionally skipped.

Finally, TemplateProcessingSteps has to be added to the Configuration steps list:


private static List<CodeGenerationStep> codeGenerationSteps() {
    return Arrays.asList(
                    ...
            //Java
            new ReadmeFileGenerationStep(),
            new ApplicationSettingsGenerationStep(),
            new ValueObjectGenerationStep(),
            new ModelGenerationStep(),
            new DataObjectGenerationStep()
            
            ....
    );

Eventually, some peripheral points in the code are also involved. The following list is mainly related when a new template file is added:

1. Create an enum value in Template passing the template filename (without extension) in the constructor. Example:


    public enum Template {

        //Other template filenames

        AGGREGATE_PROTOCOL("AggregateProtocol")

        //Enum attributes
    }

2. Map the new standard file to an existing TemplateStandard or create one. Sometimes there are multiple files for the same standard. For instance, there is one Aggregate template file for each Storage (Journal, State Store, Object Store). That means TemplateStandard is responsible for grouping template files by standard and helps the TemplateProcessor to find the proper file based on TemplateParameters such as StorageType. The examples below demonstrate the Aggregate Protocol and Value Object standards.

public enum JavaTemplateStandard {
    
    AGGREGATE_PROTOCOL(parameters -> Template.AGGREGATE_PROTOCOL.filename),
    VALUE_OBJECT(parameters -> Template.VALUE_OBJECT.filename),

    //Other standards
}

3. In case it doesn't already exist, create an enum value in TemplateParameter for each template parameter.

To sum up, those are the common steps regarding code template files on xoom-designer. Our team is available to discuss and provide more information on Gitter and our public Slack workspace.

PreviousXOOM DesignerNextEnd-to-End Tests

Last updated