VLINGO XOOM
  • Introduction
  • Overview
    • Quick Reference
  • Getting Started
    • Hello, World!
  • Architecture
  • XOOM Cloud
    • AWS Infrastructure
    • XOOM Cloud Operator
    • XOOM Cloud Demo
  • XOOM Designer
    • Development Guide
      • End-to-End Tests
  • Turbo
    • Annotations
    • Scooter
  • Actors
  • HTTP (REST and RPC)
  • Lattice
    • CQRS
    • Object, Stateful, and Sourced Entities With CQRS
    • Grid
    • Exchange
    • Processes
    • Spaces
    • Projections
    • Routers
  • Streams
  • Schemata
  • GraphQL Server
  • Symbio (Reactive Storage)
    • Journal Storage
    • State Storage
    • Object Storage
    • Adapters
  • Cluster
  • Directory
  • Common Tools
  • Build Plugins
  • Telemetry
  • Wire
  • Auth-Auth
  • Containerization
  • Tools and Patterns for Specific Use Cases
  • Appendix A: Deploy to Pivotal Cloud Foundry
  • FAQ
Powered by GitBook
On this page
  • Features
  • Introduction to CLI
  • Introduction to Designer
  • Model Processing Steps
  • Create / Update Code Templates
  1. XOOM Designer

Development Guide

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

PreviousXOOM DesignerNextEnd-to-End Tests

Last updated 3 years ago

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 , 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 class:

public class CommandLineInterfaceInitializer { 

  public static void main(final String[] args) {  
      ...
      
      final Task task = Task.triggeredBy(resolveCommand(args));      
      
      runTask(task, Arrays.asList(args));  
  }
 
  ...
}
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

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:

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:

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()));
    }
  }
  
  ...
}
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) {
      ...
    }
  }

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:

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)
    );
  }

}
  • 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;

Create / Update Code Templates

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

  • A Freemarker template file

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>

}
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;
  }

}
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);
  }

}

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:


    public enum Template {

        //Other template filenames

        AGGREGATE_PROTOCOL("AggregateProtocol")

        //Enum attributes
    }
public enum JavaTemplateStandard {
    
    AGGREGATE_PROTOCOL(parameters -> Template.AGGREGATE_PROTOCOL.filename),
    VALUE_OBJECT(parameters -> Template.VALUE_OBJECT.filename),

    //Other standards
}

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 responsible for initializing the Designer service is demonstrated:

The concluding step of a Task implementation is to edit the 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:

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

The figure above shows the two requests submitted when the user finishes the Designer model and clicks . 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:

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

Reading the code from the top, it's clear that its constructor receives a list. The details of this 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.

ModelProcessingManager.validate - checks if the submitted is valid. Otherwise, the project generation fails.

ModelProcessingManager.mapContext - maps a to that gathers all the information required for the

ModelProcessing.processSteps - iterates through the list and processes the steps when the CodeGenerationStep.shouldProcess returns true.

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

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 values to be used in the later steps.

The core steps, declared between the preliminary and concluding steps, extend which is a subclass of . 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 extensions that respectively perform the following tasks:

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

A implementation

A implementation

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

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

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

Finally, has to be added to the steps list:

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

2. Map the new standard file to an existing 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 is responsible for grouping template files by standard and helps theto find the proper file based on such as . The examples below demonstrate the Aggregate Protocol and Value Object standards.

3. In case it doesn't already exist, create an enum value in 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 and our .

installed
CommandLineInterfaceInitializer
implementation
ComponentRegistration
Svelte
Apache FreeMarker
the generate button
ModelProcessingResource
ModelProcessingManager
ModelProcessingManager
ModelProcessingManager
CodeGenerationStep
ModelProcessingManager
DesignerModel
DesignerModel
CodeGenerationContext
CodeGenerationSteps
CodeGenerationStep
CodeGenerationStep
TemplateParameter
TemplateProcessingStep
CodeGenerationStep
CodeGenerationStep
CodeGenerationStep
io.vlingo.xoom.codegen.template.TemplateData
io.vlingo.xoom.codegen.template.TemplateProcessingStep
Aggregate Protocol template file
AggregateProtocolTemplateData
TemplateData
filename method
TemplateStandard
ModelGenerationStep
ModelTemplateDataFactory
AggregateProtocolTemplateData
shouldProcess method
TemplateProcessingStep
TemplateProcessingSteps
Configuration
Template
TemplateStandard
TemplateStandard
TemplateProcessor
TemplateParameters
StorageType
TemplateParameter
Gitter
public Slack workspace
XOOM Designer components
Project Generation - UI and Rest API communication