Re: [Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
yuppie wrote: Or would be 'GenericSetup.content' enough? Yes, that looks nicer to me :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Tres!
Tres Seaver wrote:
Hmm, it seems like that landed in the project-local repository from
which GenericSetup originally sprang, but *after* GenericSetup landed in
CMF's repository. I'm attaching the patch:
- It uses the '_notes' field both to create an OFS.Image.File log of
import runs, as well as to display at the bottom of the Import
tab.
- It echoes logged messages to zLOG.
- It expands ISetupContext's API with methods 'note', 'listNotes',
and 'clearNotes'. Stock implementations of ths API are in a new
'SetupContextBase' class.
Note that the patch doesn't apply cleanly to the GenericSetup trunk;
I'll have to work out why if we chose to land it.
OK, I've landed it (it was easier than I expected) on a new branch:
http://svn.zope.org/CMF/branches/tseaver-resync_GenericSetup
I tried hard to make the I/O adapters reusable outside GenericSetup. To
become more independent from ISetupContext I propose to move the logging
API into a separate interface and class. ISetupContext would just have a
getLogger() method.
I'm also missing different logging levels. The python logging module has
a nice generic API for that.
So I propose to use the same interface for the GenericSetup specific
logger, making it replaceable by a python logger if the I/O handlers are
used in a different context.
For example this code in content.py::
import_context.note('SGAIFA',
'no .ini file for %s/%s' % (subdir, cid))
would be replaced by this code::
logger = import_context.getLogger('SGAIFA')
logger.info('no .ini file for %s/%s' % (subdir, cid))
If there are no objections I'd like to make those changes either on your
branch or after you merged your changes into the trunk.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Tres! Tres Seaver wrote: If there are no objections I'd like to make those changes either on your branch or after you merged your changes into the trunk. Go ahead and merge it to the branch -- I'll need to look at how the generated report changes to reflect the level. Done. The logger names are still a mess. Currently we have names on 3 levels: - product: 'GenericSetup' - setup step/handler ID: e.g. 'rolemap', 'toolset' - adapter/'component': e.g. 'SFWA', 'CSAFA' (BTW: what means 'SGAIFA'?) Should we combine all 3 levels in the dotted logger name? e.g. 'GenericSetup.content.CSAFA' Or would be 'GenericSetup.content' enough? Currently it is 'GenericSetup.CSAFA'. Maybe you've got an idea how to resolve this. Don't know what kind of 'component' name the reports need. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Chris! Chris Withers wrote: Jens Vagelpohl wrote: There could be a multiplexer that logs to the standard Zope event log *and* keeps the messages in a memory buffer to be displayed in the browser. This could be done in a separate class or a logging API could be added to ISetupContext. Should be easy to do, really. Well, this is all supported by the logging module ;-) You can define a new log handler just for the duration of the process and then remove it. Have a look at MailingLogger's SummarisingLogger for ideas. Give it a go and let me know where the code is if you want me to take a look, I've got to know and love python's logging module quite well ;-) I had a quick look at MailingLogger, but it seems to do something different. We need 'per request' reports to give instant feedback in the setup tool. The logging module is not aware of requests, so I can't see an easy way to make sure the log handler collects only messages for a specific request. Or am I missing something? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 15 Nov 2005, at 14:24, yuppie wrote: The notes should be logged *and* used for reporting in the ZMI. Implementation: I'm no logging expert, so I might well be missing something. The state of the art seems to be using the Python logging package (PEP 282). Is it possible to use that framework for reporting as well? It doesn't look like that. Replacing the 'note' method in ISetupContext with a more logger like API and sending the notes to the Python logger *and* to TTW reports might be the way to go. There could be a multiplexer that logs to the standard Zope event log *and* keeps the messages in a memory buffer to be displayed in the browser. This could be done in a separate class or a logging API could be added to ISetupContext. Should be easy to do, really. I *think* the current setup tool creates a text file with log messages in it, and stores that file inside the tool. I would prefer to maintain the data persistently, rather than in RAM; the API for that could be extended, of course. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDekyJ+gerLs4ltQ4RApNNAKCMFTWqwLFrhl3618ecitJPQYB8zwCgkMhT k0O0Ef4I2DTQhHMactiF/CM= =NOSF -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
