Entry point for each request is the
Jtl\Connector\Core\Application\Application class. To properly serve the request, you should
create an instance of a connector application with desired parameters and options and call the
Jtl\Connector\Core\Connector\ConnectorInterface $connector- instance of endpoint
string $connectorDir- root path to endpoint
Noodlehaus\ConfigInterface $config- (optional) config object for use in core and endpoint
Jtl\Connector\Core\Config\ConfigSchema $configSchema- (optional) definition of what config object should have to be valid. If you want to know more about the config schema please check the configuration chapter
The application provides some methods to replace the default used instances:
setSessionHandler- by default the
Jtl\Connector\Core\Session\SqliteSessionHandleris used but it can be replaced by another handler. A Symfony session handler could be used for instance.
If you want to use a Symfony session handler, then you can create an anonymous class which implements the
Jtl\Connector\Core\Session\SessionHandlerInterfaceinterface and extends the session handler class.
$application->setSessionHandler(new class($pdoOrDsn) implements SessionHandlerInterface extends PdoSessionHandler);
setErrorHandler- by default
Jtl\Connector\Core\Error\ErrorHandlercan be changed to another handler which extends
registerController- if you want to register a controller which does not match the default controller name pattern (or any other reason). You can check the constants defined in the class
Jtl\Connector\Core\Definition\Controllerfor all valid controller names in the Core.
Please keep in mind that changing the default behaviour of the core requires some advanced knowledge about how the core works.
The application class is using a DI container for handling objects and dependencies internally. Because of that it is possible to overwrite most of code functionalities by your own objects.
Incoming requests are handled by the application in the
handleRequest method by default. It should contain all required logic to process the request.
handleRequest method does not match the requirements for your endpoint, it is also possible to handle the request directly in the endpoint. In order to achieve this, the connector class from the endpoint
must implement the
Subscribers (I/O data manipulations)¶
We are using some data manipulators to change the input and output data in the Core. In this case the data manipulations are related to the de-/serialization of JSON requests and responses.
If you want to know more about handlers and subscribers, please take a look at jms/serializer.
Jtl\Connector\Core\Serializer\SerializerBuilder class are some events subscribed and
handlers added, for being able to properly de-/serializing the Core models. All manipulations are adapted to the current models so there is no need to modify model properties by your own.
For instance the subscriber
Jtl\Connector\Core\Serializer\Subscriber\LanguageIsoSubscriber is responsible for converting the language
ISO standard from ISO-639-2/B to ISO-639-1 and vice versa.
All translatable core models own a property called
languageIso (ISO-639-1). Before a translatable model will be send to JTL-Wawi the
languageIso property must be transformed into
languageISO (ISO-639-2/B), because it is standard in JTL-Connector.
The subscriber transforms the language property for de-/serialization, so connector developers do not need to take care about.