Paolo Bonzini schrieb:
My idea of the class hierarchy would be:
OutputHandler
StreamOutputHandler
TextOutputHandler
HTMLOutputHandler
SyslogOutputHandler
MultiplexOutputHandler
(Of course not everything needs to be there to include the logging in gst).
What do you think?
Hi!
Ok, here I see, that an OutputHandler for you is the combination of (in
the case of my logging currently implemented) a formatter and an Output
(or Log-) Handler. (Which is called "channel" in my current
implementation. This is currently not an Object, just a Dictionary with
the fields for outputSeverity, logHandler and formatter).
I think I should explain in short, how my logging is currently working.
A logger for a category could have several output-channels, which could
be active for the same time. (if you have several channels active
[output-severity > NONE], a single log-message is printed on each of the
channels).
Each channel is a combination of a LogHandler (currently to a File or to
the transcript, in future even to a stream) and a selected formatter
(text or html-format currently) you can combine the formatter and the
logHandler as you like, so that you could log in html to the transcript
or (with the stream) to a socket. (Or you'll could handle the stream by
your own).
(or you can implement your own logHandler or formatter and provide an
instance of it to the channel)
The formatter accepts a LogEntry-Object(*) as the input and returns a
string of the log-information. The logHandler accepts the string and
direct it to the desired output.
So the code of the log-message output for each channel is like this:
logHandler log: (formatter format: logEntry).
(Ok, there's additionally a switch for determine, if the output to this
channel has already started, for the start and end work for each
formatting and output, but that's only a detail...)
- Do you think, that this what currently is implemented as only a
Dictionary should go into the former mentioned class-hierachy of objects?
- Maybe I would need some more information, of how you think the
decorators should work...
(*)
The log-method itselfs creates eventually an Object (I would say a
ValueObject) with the information of the message.
The call would be: "logger logError: 'This is an error'." and the
log-method would generate an Object with the infos:
- category
- date
- time
- severity
- classname in which the logError was called ---
- methodname in which the logError was called |
- filename |
- line > got from the context
- lineInFile |
- message ---
(Hope I haven't wrote too much...)
Regards,
Joachim.
_______________________________________________
help-smalltalk mailing list
help-smalltalk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
