Hi there,

this is a suggestion I welcome very much. Thanks for taking the initiative on this one.

We have to discuss how we can migrate from the existing solution to the new one.

If your code doesn't affect any existing behaviour, you could add it to trunk right away.

Christoph


Astrid Emde schrieb:
Hello Karim,

thanks for your input.

Your suggestion sounds quite sympathic to me.

Maybe we wait till Christoph is back and discuss it with him.

If we want to implement it, it may make sense to take it to the next
version (2.8) and not to 2.7. Or will it be ok for 2.7?

You could make a ticket in trac for this change.

Best regards astrid



On Mon, February 8, 2010 5:54 pm, Karim Malhas wrote:
Dear All,


I recently looked into what Mapbender offers as it's logging options,
and I found this : //if you are familiar with the logging code, skip down
to "While this works";

Clientside:


classes in lib/exception.js: Mapbender.Exception, Mapbender.Warning,
Mapbender.Notice
all derived from the class Mb_log

usage:
new Mapbender.Exception("exeption message goes here");

The different classes differ internally in that they call
Mb_log.throwException(message,level) with different levels
this function in return checks if the loglevel is defined somewhere
globally, and then depending on the value of another global variable,
either posts the stuff to the server, issues a console.log, or simply
alerts.

If the logmessage reaches the serverside, they are translated into
an approximate serverside log-equivalent (php/mb_js_exception.php)


Serverside


classes:
mb_exception, mb_warning, mb_notice all derived from mb_log (which is an
abstract class)

usage:
$e = new mb_exception("exception message goes here");
$e = new mb_warning("warning message goes here");


The same way as the javascript logging classes, the difference between
these different classes, ist just that they internally set a different
string and pass it to the mb_log method they inherted from mb_log (the
class) The messages end up in the "log/" directory of the Mapbender
installation.





While this works, to me this is not an ideal situation.


- The code mixes the concepts of Logging and Exceptions:
When I think of Exceptions, I think of objects that can be thrown and
caught, and when neccesary, logged to the DEBUG (or some other) level. But
not every Exceptions needs to generate a log entry, rather, it should be
dealt with, bubbled up, and only if all else fails should the user (via
some kind of notification) or the developer (via the log) be informed of a
problem.

- All logs go to a file, or configurable from core/system.php to FireBug
There's no flexible way to change the location of the logfile (one has
to change php/classes_mb_log.php). There's also no way to log to syslog,
for example


So I propose we change it :-) maybe not right now, but we could keep it
in mind.

I am thinking something along the lines of the following:


Clientside:


var log = new Logger("mapbender_installation_5);

var alertHandler = new AlertHandler(); log.addHandler(alertHandler);

var serverHandler = new ServerHandler("log.php");
log.addHandler(serverHandler);


log.notice("mapbender is starting up"); ...
log.debug("loaded 24 elements"); try{ ...
}catch(E){
if (E instanceOf TypeError){ // tell user to enter better data
return; }


// all else failed
log.debug("caught Exception in the_method(): "+ E); // tell user that
evreything went horribly wrong and they should // try turning it off and
on again }


(and something similar for serverside php)



So there are two components to generating the log message:


- a Logger class that takes care about which loglevels to provide, and
which loglevels to log

- a logHandler class that actually formats and writes a logmessage.
On the client side, the message could go into an alert, the console,
written onto the page itself, displayed in a jquery dialog, set to the
server, etc On the Server side the message could go into the normal
mapbender log, to syslog, Firebug, the Windows eventlog, and wherever else
you could want it.

I am especially after being able taking advantage of syslog.



I actually have a (mostly complete) implementation of the above, and I
was wondering if anyone else is interested in having this integrated.

Maybe it's not the right time, with a release coming up, but it has
bothered me a bit for a while.


Regards,
Karim


_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev






--

********************************************
FOSSGIS Konferenz 2010
2. - 5. März 2010 in Osnabrück
http://www.fossgis.de/konferenz
********************************************

----------------------------------

Aufwind durch Wissen!

Qualifizierte OpenSource-Schulungen
bei der www.foss-academy.eu

----------------------------------
_______________________________________

W h e r e G r o u p GmbH & Co. KG

Siemensstraße 8
53121 Bonn
Germany

Christoph Baudson
Anwendungsentwickler

Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[email protected]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev

Reply via email to