You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TransformationEngine should accept a PSR-3 logger implementation and route it through to the transformers. This is a standardized way of letting the consumer of the library decide how and when to accept logging information and is mandatory in larger projects to maintain control over the different parts of the system.
The library should also include a logger implementation that can be used (or will be used by default, TBD) that logs errors into HTML comments, as a sort of last resort to communicating error conditions in an HTTP stack that doesn't come with its own PSR-3 routing.
In the future, the validator and the sanitizer engines should accept such a PSR-3 logger as well.
The text was updated successfully, but these errors were encountered:
We already have the ErrorCollection object which is mandatory and collects actual errors within the Optimizer.
The logger would be optional and maybe complementary to that and collect purely informational and/or debugging information. It could also forward the errors added to the ErrorCollection as well, so that log files contain the complete picture of what the system is going through.
The way a PSR-3 logger is usually handled is that, at the very least, you pass a NullLogger around (see NullObject design pattern) and all the places where logging makes sense just blindly log into whatever logging instance they received.
Then, the outside/consuming code can decide what logging functionality is needed and pass the corresponding implementation into the system via dependency injection.
This is different than the ErrorCollection object that we currently have for errors, because that one:
is required and clearly communicated as being the "return value" mechanism of the optimizer;
deals only with errors and mustn't be abused for informational/debugging messages;
is a simple bag that collects these errors to make them easy to pass around;
cannot take care of routing/dispatching/orchestrating/etc... which might be needed for higher throughput messaging.
Food for thought:
Is the ErrorCollection object really needed, or would it be preferable to have a PSR-3 logger only which covers the entire spectrum of feedback (debug, info, warnings & errors in several severities)?
Is it preferable to use both for semantically separating the two concepts of "providing generic output" & "gathering a list of encountered errors"?
The
TransformationEngine
should accept a PSR-3 logger implementation and route it through to the transformers. This is a standardized way of letting the consumer of the library decide how and when to accept logging information and is mandatory in larger projects to maintain control over the different parts of the system.The library should also include a logger implementation that can be used (or will be used by default, TBD) that logs errors into HTML comments, as a sort of last resort to communicating error conditions in an HTTP stack that doesn't come with its own PSR-3 routing.
In the future, the validator and the sanitizer engines should accept such a PSR-3 logger as well.
The text was updated successfully, but these errors were encountered: