Разработка системы регистрации

Question

У меня есть программа, которая должна обрабатывать файлы в пакетном режиме. Вместо того, чтобы показывать ошибки в окнах сообщений на экране (что приостанавливает выполнение программы), мне нужно показать эти сообщения об ошибках в журнале, который пользователь может видеть по мере выполнения программы.

Так что я не нужен журнал программа-исполнение, как этот Which logging library is better?

Я использую сейчас что-то производное от TRichEdit. В основном, богатые редактирования с несколькими дополнительными методами, как AddError (ов), AddWarn (ов), AddVerbose (ов) и т.д.

TRichLog = class(TMyRichEdit) 
    private 
    protected 
    Indent: Integer; { Indent new added lines x spaces } 
    public 
    constructor Create(AOwner: TComponent); override; 
    procedure AddBold  (CONST Mesaj: string); 
    procedure AddMsg  (CONST Mesaj: string); 
    procedure AddMsgLvl (CONST Mesaj: string; MsgType: Integer); 
    procedure AddColorMsg (CONST Mesaj: string; Culoare: TColor); 
    procedure AddVerb  (CONST Mesaj: string); 
    procedure AddHint  (CONST Mesaj: string); 
    procedure AddInfo  (CONST Mesaj: string); 
    procedure AddPath  (CONST Mesaj: string); 
    procedure AddWarn  (CONST Mesaj: string); 
    procedure AddError (CONST Mesaj: string); 
    procedure AddMsgInt (CONST Mesaj: string; i: Integer);   { Adds a message text followed by an integer } 
    procedure AddInteger (CONST i: Integer); 
    procedure AddFromFile (CONST FileName: string; MsgType: Integer);        { Reads lines from the specified file and adds them to the log using the specified color. } 
    procedure AddEmptyRow; 
    procedure AddDateStamp; 

    procedure Append (RamLog: TObject);  { RamLog will be typecased to TRamLog } 
    procedure SaveAsRtf (CONST FullPath: string); 
    procedure AppendToFile(CONST FullPath: string); 
    function VerbosityAsString: string; 
    published 
    property InsertTime: Boolean  read FInsertTime write FInsertTime default FALSE; 
    property InsertDate: Boolean  read FInsertDate write FInsertDate default FALSE; 
    property AutoScroll: Boolean  read FAutoScroll write FAutoScroll default TRUE;   { Automatically scroll to show the last line } 
    property Verbosity : Integer  read FVerbosity write FVerbosity default vHints; 

    property OnLogError: TNotifyEvent read FLogError write FLogError;       { Can be used to inform the application to automatically switch to log when an error is listed } 
    property OnLogWarn : TNotifyEvent read FLogWarn write FLogWarn; 

Но я хотел бы, чтобы пользователь динамически фильтровать контекст. Например, пользователь должен иметь возможность скрывать все сообщения Verbose и сохранять только предупреждения и ошибки. И если пользователь передумает, верните подробные сообщения.

Можно ли отфильтровать (существующий) текст в RichEdit таким образом? Если нет, я хотел бы получить несколько указаний о том, как переопределить его. Я думаю о написании собственного формата для сохранения строк/сообщений. Например:

не может открыть файл, # MsgErr, # Жирный

я бы TStringGrid, чтобы отобразить только ограниченное количество строк (те, которые видны на экране). Таким образом, я мог бы иметь миллионы строк без фактического отображения их всех на экране. Время, затрачиваемое на разбор, не имеет значения, так как мне нужно только разобрать видимые строки.

Требования:

• Поддержка цветов, как в RichEdit (красный на наличие ошибок и т.д.)
• Lightweight
• должны иметь два класса: визуальный один (на основе TStringGrid) и один невизуальный для консольных программ (войдите в ОЗУ и сохраните журнал позже или покажите сообщения как простой текст в консоли). не
• Нет жестких зависимостей (Delphi издание, Инди, двигатели DB, 3-й управляет партия и т.д.)
• Малые (TRichEdit увеличивает размер файла EXE довольно много)
• Один PAS файл

альтернативой было бы не использовать Grid и самостоятельно рисовать текст (например, в компоненте, основанном на TPanel). Или, может быть, такой контроль уже существует.

Любые конструктивные критики моих идей приветствуются. У вас есть идея лучше, чем использование Grid?

Answer 1

ИМХО мы можем сделать разницу между:

• протоколирования низкого уровня, которая ориентирована на разработчиков и поддержки;
• Высокоуровневое протоколирование, предназначенное для конечных пользователей.

Из ваших комментариев звучит так, будто вам нужен второй вид, который обычно также называется «Аудиторский след», особенно в терминах или правилах.

Обычно мы используем «Audit Trail» на высоком уровне, сохраняя события в базе данных. Например, локальная высокопроизводительная база данных SQLite3 или централизованный экземпляр MongoDB.

Использование СУБД (или NoSQL БД) имеет ряд преимуществ:

• Его структура может быть одновременно фиксированной (например, путем определения категорий) и развивающего (через несколько текстовых полей, или даже некоторые иностранные ключи с другими таблицами);
• Легко взаимодействовать с существующим пользовательским интерфейсом, например. использование мощных сторонних сетей с возможностью сортировки и фильтрации;
• Вы можете использовать SQL для поиска в содержимом журнала, а затем определить определенный пользовательский интерфейс для наиболее полезных случаев;
• Прост в обслуживании (DELETE FROM ... будет избавляться от старых незавершенных записей и потенциально содержать ошибки в базе данных).

Мы обычно делаем это на производстве, используя our Open Source SOA framework: все вызовы служб могут быть записаны непосредственно в экземпляре sqlite3 или MongoDB, without any code to write! Затем вы можете даже выполнять поиск по параметрам с помощью запросов JSON. И у вас все еще есть integrated low-level logging available.