Discussing the article: "Mastering Log Records (Part 9): Implementing the builder pattern and adding default configurations"

New comment
 

Check out the new article: Mastering Log Records (Part 9): Implementing the builder pattern and adding default configurations.

This article shows how to drastically simplify the use of the Logify library with the Builder pattern and automatic default configurations. It explains the structure of the specialized builders, how to use them with smart auto-completion, and how to ensure a functional log even without manual configuration. It also covers tweaks for MetaTrader 5 build 5100.

Since I started using Logify in various personal and professional projects, I quickly realized that the biggest challenge was not in the robustness or functionality of the library itself, but in its configuration. Logify is a powerful tool for managing logs in Expert Advisors, offering multiple handlers, log levels, customized formats, language support and much more. All of this, however, required the user to configure each handler, formatter and parameter manually, which may work well for small projects, but which quickly becomes a repetitive, tiresome and error-prone task as the number of EAs and projects grows.

Imagine having to replicate, for each EA, the same complex set of configurations: creating specific handlers for tab commenting, console, files, databases; setting minimum levels for each handler; defining specific formats for error messages, debugging, alerts, and so on. Each of these steps, although necessary, generates long, detailed and unintuitive code, breaking the flow of development. This initial complexity becomes a barrier, a friction that can discourage the adoption of Logify, even if it offers impeccable log management at runtime.

This insight motivated me to think: how can I make this configuration easier, simplifying the user's life, without giving up flexibility and customization? It was at this point that the idea of creating a builder for Logify was born, a class that allows you to assemble the entire configuration in a fluid, chained way, with intuitive methods that create handlers with sensible patterns and allow quick, localized adjustments. The aim is to transform dozens of lines of configuration into a few method calls, almost as if we were writing a clear summary of what we want, rather than all the manual assembly.

In this article, I'll show you how I've implemented these improvements. I'll introduce the builder, explaining its design and use. Then I'll demonstrate how Logify can be configured with practical examples.

Author: joaopedrodev

 

Have you considered adding runtime stop logging? Of course, it is normal for the developer to handle this in the EA.

  
TerminalInfoString(TERMINAL_LANGUAGE);

The default error output language of the log can be returned to the user's terminal language according to this code

 

I am wondering if I want to output Debug and Error messages only. And I have all the Info, Alert, etc built into the EA. Maybe to set a bool value for every type in 'enum ENUM_LOG_LEVEL' to show what we want?

For production code, if we turn some of the logs off, it should not be compiled into the final ex5 file.

 
Spoxus Spoxus #:

I am wondering if I want to output Debug and Error messages only. And I have all the Info, Alert, etc built into the EA. Maybe to set a bool value for every type in 'enum ENUM_LOG_LEVEL' to show what we want?

For production code, if we turn some of the logs off, it should not be compiled into the final ex5 file.

To do this, you can use a variable or even an IP address in the expert that stores the desired level value and simply passes it to the handler. Here's an example.

//+------------------------------------------------------------------+
//| Import                                                           |
//+------------------------------------------------------------------+
#include <Logify/Logify.mqh>
CLogify Logify;
//+------------------------------------------------------------------+
//| Inputs                                                           |
//+------------------------------------------------------------------+
input ENUM_LOG_LEVEL InpLogLevel = LOG_LEVEL_INFO; // Log level
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   Logify.EnsureDefaultHandler();
   Logify.GetHandler(0).SetLevel(InpLogLevel);
   
   Logify.Debug("RSI indicator value calculated: 72.56", "Indicators", "Period: 14");
   Logify.Info("Buy order sent successfully", "Order Management", "Symbol: EURUSD, Volume: 0.1");
   Logify.Error("Failed to send sell order", 10016,"Order Management");
   
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+

This will display only messages with a severity level greater than or equal to the one defined in the handler.

 
hini #:

The default error output language of the log can be returned to the user's terminal language according to this code

Part 10 of this article is in the queue for publication. It discusses a way to suppress identical logs and also sets the default language for the terminal. Thanks for the suggestion!

New comment