[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> Hi Tres!
> 
> 
> Tres Seaver wrote:
> 
>> 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.
> 
> 
> Couldn't find anything like that in the setup tool. It collects the
> messages returned by handlers, passes them around and forgets them after
> the request is finished. The _notes list of the setup context is ignored
> completely by the tool.

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.

>> I would prefer to maintain
>> the data persistently, rather than in RAM;  the API for that could be
>> extended, of course.
> 
> 
> Why would you prefer persistent reports? Wouldn't it be sufficient to
> have the messages in the event log?

Having the log file present in the tool makes it possible to review what
happened without having filesystem access, which was importante for the
customer whose project inspired the non-CMF-specific GenericSetup.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDeyi5+gerLs4ltQ4RAkmOAJ0YDoKjTsJWoYdfeNnmSFjjt5bngQCfRVVH
wt7dJmn0rRihR1EFZ5PVEV8=
=ym+y
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gs-0.10-0.12.patch
Type: text/x-patch
Size: 20028 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-cmf/attachments/20051116/7b9af9f0/gs-0.10-0.12-0001.bin