[izpack-devel] FW: Logging -> need feedback (API included)

[Klaus Bartz]

Hi Elmar,
today morning I have looked a little bit into the sources. Seems
nice. But I have had no time to make something with it.
Am I right that you have no line to IzPacks svn? If so, should I
check in the sources? Will be better if I add the stuff to
FinishPanel etc.

Cheers

Klaus


Am 12.12.2006, 18:59 Uhr, schrieb Elmar Grom <elmar at grom.net>:

> Hi Klaus,
>
> for reference I have included the code, so that you can have a look at  
> the
> API.
>
>
>>> 4) it can build a localized text report and provides the
>>> necessary UI to save the report to a file of the users choice.
>>
>> May be configurable. Other installer writes logging also without
>> asking the user. May be we can declare central a support directory
>> where also other loggings can be stored (e.g. the summary).
>
> Yes that could be done. Are you thinking about a fixed location and  
> name, so
> that the configuration just turns this on/off or rather about specifying  
> a
> path and name in the configuration?
>
>
>>> 5) there is special handling support for use of (4) in an automated
>>> installer. In this case a message dialog is popped up that
>>> also allows the
>>> user to save the report if there are any warning or error
>>> messages recorded.
>>
>> Have to be configurable because there are installations without
>> user interaction.
>
> Same as above.
>
>
>>> 1) the two finish panels need to be upgraded to display a
>>> generic message
>>> 2) the two finish panels need to be upgraded to provide a
>>> button for saving
>>> the report
>>
>> I have to see the impl or the docu to see whether I understand
>> the usage or not :-) If so, I can do 1) and 2).
>
> OK, the code is included. Have a look at
>
> warningsRecorded ()
> errorsRecorded ()
>
> The finish panel would call these methods and display an appropriate  
> message
> if either one returns true. This would also be the signal to make a  
> button
> available for writing the report. If the button is clicked just call
>
> writeReport ()
>
> The complete user interface is already provided.
>
> The automated installer would simply call
>
> informUser ()
>
> This method also verifies if there are any error or warning messages. It
> provides the complete UI (pops up a dialog with a button to write the log
> etc.).
>
>
>>> 5) what should be done if the developer decides not to use a
>>> finish panel or
>>> wants to write his own?
>>
>> If some one will not say good by, he has bad luck. We should not
>> support discourteousness with a hack from us for it :-)
>
> Well, you are probably right. This would have to be made really clear in  
> the
> documentation though.
>
>> May be this is a good reason to bring together FinishPPanel and
>> SimpleFinishPanel. At upgrading the two panels create a base class
>> which makes all common stuff. A developer which needs an own
>> finish panel should be used then this base. If not, he has also bad  
>> luck...
>
> I think this is a really good idea.
>
>
>>> 7) there are LOTS of messages to be translated ~:o)
>>
>> I assume that you make the English and the German. Therefore there is
>> no part for me :-)
>
> Well, up to a point. There is quite some text for the dialogs etc. and  
> then
> there are headings and generic messages for the report. I have done all  
> of
> those in English and German. Then there will be all the specific messages
> that folks will implement. Those are a different matter of course.
>
> There is a complete explanation on how to implement new messages in the
> documentation header for the Log class.
>
>
>> If system exist, I will do it in my stuff.
>> What about to publish the panel list where developer will be insert
>> his mnemonic.
>
> This is my only worry at this point, that we have the log system but  
> actual
> logging is only spotty. We should make sure that at least all the  
> critical
> stuff has logging.
>
> I am not sure what you mean with the list. Can you please elaborate?
>
> Cheers
>
> 	Elmar
>
> -----Original Message-----
> From: Bartz, Klaus [mailto:Klaus.Bartz at coi.de]
> Sent: Tuesday, December 12, 2006 12:37 AM
> To: elmar at grom.net; izpack-devel at lists.berlios.de
> Subject: RE: [izpack-devel] Logging -> need feedback
>
>
> Hi Elmar,
> I am waiting for it :-)
> You know, I think it will be nice if there are "slots"
> additional to types of events to keep track of if there are
> many logs of type message. You know the situation where a
> log file containts a MB informations.
> But it is only a wish of me.
> Rest context related.
>
> Cheers
>
> Klaus
>
>> -----Original Message-----
>> From: izpack-devel-bounces at lists.berlios.de
>> [mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Elmar Grom
>> Sent: Tuesday, December 12, 2006 6:27 AM
>> To: Izpack
>> Subject: [izpack-devel] Logging -> need feedback
>>
>>
>> Hi everybody,
>>
>> sorry, I was spaced out for a bit, wanted to send this earlier
>> but a lot was
>> going on in my world... anyway, here we continue with logging
>>
>> Please send comments, proposals etc. and let me know if you can help a
>> little with this project. There is still some work to be done on many
>> fronts, though none of it should be a major amount.
>>
>>
>> What has happened and what is implemented so far?
>> =================================================
>>
>> So far I have implemented a logger class and modified it
>> according to some
>> feedback I received. This class can do the following:
>>
>> 1) it can be used to log any event of interest during an installation
>> 2) depending on the types of events recorded
>> (message/warning/error) the
>> class provides flags for the GUI to present an appropriate
>> generic message
>> 3) an exception can be attached to warning and error messages
>> 4) it can build a localized text report and provides the
>> necessary UI to
>> save the report to a file of the users choice.
>
>
> May be configurable. Other installer writes logging also without
> asking the user. May be we can declare central a support directory
> where also other loggings can be stored (e.g. the summary).
>
>
>> 5) there is special handling support for use of (4) in an automated
>> installer. In this case a message dialog is popped up that
>> also allows the
>> user to save the report if there are any warning or error
>> messages recorded.
>
>
> Have to be configurable because there are installations without
> user interaction.
>
>
>>
>>
>> What needs to be decided and what is yet to be implemented?
>> ===========================================================
>>
>> 1) the two finish panels need to be upgraded to display a
>> generic message
>> indicating installation success
>> 2) the two finish panels need to be upgraded to provide a
>> button for saving
>> the report
>
>
> I have to see the impl or the docu to see whether I understand
> the usage or not :-) If so, I can do 1) and 2).
>
>> 3) Log needs to integrated with the project (who can check the
>> code in for
>> me?)
>> 4) Julien has proposed to add a GUI element to the installer frame that
>> displays a message if a warning or error was recorded. This
>> would have to be
>> implemented and wired with the logger for updating.
>> 5) what should be done if the developer decides not to use a
>> finish panel or
>> wants to write his own?
>
> If some one will not say good by, he has bad luck. We should not
> support discourteousness with a hack from us for it :-)
>
> May be this is a good reason to bring together FinishPPanel and
> SimpleFinishPanel. At upgrading the two panels create a base class
> which makes all common stuff. A developer which needs an own
> finish panel should be used then this base. If not, he has also bad  
> luck...
>
>
>> 6) some re-factoring work is required surrounding InstallData
>> 7) there are LOTS of messages to be translated ~:o)
>
> I assume that you make the English and the German. Therefore there is
> no part for me :-)
>
>> 8) logging should be used -> implement lots of logging all
>> over the code!
>>
>
> If system exist, I will do it in my stuff.
> What about to publish the panel list where developer will be insert
> his mnemonic.
>
>>
>>
>>
>>       Elmar
>>
>> _______________________________________________
>> izpack-devel mailing list
>> izpack-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/izpack-devel
>>
>
>
> __________ NOD32 1.1392 (20060202) Information __________
>
> Diese E-Mail wurde vom NOD32 Antivirus System geprüft
> http://www.nod32.com
>



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/