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;io.vlingo.xoom.designer
and io.vlingo.xoom.cli
. ./xoom docker package
). Internally, this script runs the Designer
jar and passes the command, i.e. docker package
, to the CommandLineInterfaceInitializer class: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: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: 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: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.bash
, set like this:README.md
in the xoom-designer
repository.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:ModelProcessingManager.validate
- checks if the submitted DesignerModel is valid. Otherwise, the project generation fails.ModelProcessingManager.mapContext
- maps a DesignerModel to CodeGenerationContext that gathers all the information required for the CodeGenerationSteps​ModelProcessing.processSteps
- iterates through the CodeGenerationStep list and processes the steps when the CodeGenerationStep.shouldProcess
returns true.io.vlingo.xoom.designer.Configuration
:AggregateProtocol
class generation as an example and go through the implementation details, starting from the template file:Aggregate Protocol
class. The parameters handling and mapping are addressed by AggregateProtocolTemplateData as follows: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.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.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.code template files
on xoom-designer
. Our team is available to discuss and provide more information on Gitter and our public Slack workspace.