Symfony generated code anatomy

In this section you will find details about how Code-bay generates code for Symfony based apis projects. Keep in mind that all the code described in this chapter is auto generated and should not be modified manually as it would be overwritten at the next generation run.


Definitions are used across your apis to modelize the resources you manipulate. It can be referenced in parameters, responses and even other definitions. Technically, every definition will be generated as a class extending the CodeBay\Core\JsonMappable base class. All definitions are stored at the following location in your project workspace : ./generated/Api/Definition where Api is the default out path that you can override in the Api metadata section of your Code-bay api.


In Code-bay, every operation what is to say every method of each path must have a tag. This tag is used to generate the controller. Indeed, all operations sharing the same tag will be saved in the same controller that has the following naming structure ApislugTagController. For instance if your Api is named Acme and comprises a get operation tagged as Sample, Code-bay will generate a Controller class named AcmeSampleController. These classes are located in folder ./generated/Api/Controller by default. Technically, each controller is responsible for routing the paths you defined to the appropriate api pipeline.


For each operation id that your api is composed of, Code-bay creates several objects that will help you in processing the request. These objects are grouped by tag and operation id, their content is details below.


Context class contains all information you need to process the incoming request. It is a php class with following attributes :

  • message : the message attribute corresponds to all users parameters that can be located in path, query, body, or headers. You will find more details about messages in the next chapter.
  • response : this is the response that will be returned to the client at the end of the execution of your stages. It is initiated as a default Symfony\Component\HttpFoundation\Response and can be override anytime during the stages execution.
  • responseCodeViews : for each response you defined at the operation level, Code-bay adds a method responseCodeXXXViewwhere XXX corresponds to the HTTP code. This attribute is used by the default response handler stage to set response data. Indeed, during the response stage, if the response as a code and if the matching response view method contains data, Code-bay will try to hydrate the response with it.
  • twigTemplate : when activating an operation, Code-bay creates a default response stage that uses theCodeBay\Core\Service\DefaultResponseHandlerStage class. This class looks for the attribute twigTemplateand tries to hydrate it with response data you provided as explained in the previous section. Inside the template, hydratation data will be accessible through a data root object.
  • exception : this attribute is set by the Api pipeline in case of an exception is thrown during the execution of one one the stages. It can be useful if you want to implement your own exception handling stage and then access the exception thrown when it is called.
  • additionalContext : this attribute can be used if you want to share data between stages.

As mentioned before, all operation parameter will be saved in a message class to allow you to easily access it from your stages. For instance if you activates the put method for path /operation/{id}, and that operation takes a Operation definition object as body parameter, Code-bay will generate a message class containing two attributes :

  • id : this attribute will contain the value of the id in the path
  • body : an attribute with type Operation matching the operation definition of your Api

There are two types of stages that get generated in Code-bay. The first one, which concerns Message and Format stage are built-in stages and cannot be overriden or removed. The second are custom stages and can be managed in the Stages tab of your operations. Note that custom stages are split into two categories : business stages that are run in order when a request matches the associated operation and exception stages that get called when a exception is thrown. You can define as many business stages you want only one exception stage for a given operation.

Format stage

The format stage is a built-in stage checking that input parameters respects the format defined in your api. If any error is detected, the stage will throw a CodeBay\Core\Exception\ApiFormatException containing violations information.

Message stage

The message stage is also a built-in stage responsible for extracting parameters from the input request and setting them into the Message class associated with an operation. It gets executed directly after the format stage.

Custom stages

Once the format and message stages have been run, Code-bay executes every custom stage in the order they are defined in the operation Stages tab.

© Code-bay 2021, All rights reserved

When you visit or interact with our sites, services or tools, we use cookies for storing information to help provide you with a better, faster and safer experience. None of these cookies are used for marketing purposes.