[
https://issues.apache.org/jira/browse/CB-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266188#comment-13266188
]
Patrick Mueller commented on CB-611:
------------------------------------
bq. log4j
As someone who has suffered with log4j and it's "successors" over the years,
you're not convincing me. :-)
I'm still missing some precision here. What does this mean?
bq. add the missing functionality to the existing class
Do you mean the JS {{console}} object that is currently visible to most every
web browsing widget available? Or do you mean the "Debug Console" Cordova
plugin?
I'm reading what you're saying is that you want to standardize the additional
methods/properties that the iOS version has added to the JS {{console}} object,
across all the platforms. In which case ...
bq. If we have to add a new class every time something is missing, we will
start a path that has more and more plugins and source files. This is not a
good way forward either, since constantly adding classes will add complexity
and more than one way of doing each thing.
I'm not suggesting we add any additional plugins, assuming we re-use or
retro-fit the "Debug Console" plugin. We don't need an additional plugin or
source file to expose methods on an new JavaScript object. We're only exposing
a new object in JS.
Also, you're already suggesting "more than one way of doing each thing". My
understanding is that the existing JavaScript {{console}} object actually works
in most of the Cordova runtimes, in various flavors. Do we really want to
"patch" console.info() to take into account the current logging level? Now
you're changing existing behavior!
Here's my suggestion, based on guesses on your use case.
We create a new {{logger}} property on {{cordova}}. The primary use for this
is plugin code, not "user land" code. {{cordova.logger}} will have whatever
minimal logging level stuff we need. We'll rename the "Debug Console" plugin
to "Logger", or whatever.
For platforms that do not have a {{console}} object visible in user-land JS, or
the one that's provided is sub-par or non-operational (iOS), provide an
implementation of the FireBug Console API implemented with the new
{{cordova.logger}} object.
This leaves us with a portable, common, non-extended {{console}} object for
userland JavaScript. Something users are familiar with. They won't be
confused when they see our {{console}} has sprouted new methods. Nor will they
inadvertently leave invocations of this extended console API in their code,
only to find it throws exceptions outside of Cordova. For plugin authors who
are doing boat-loads of logging and therefore need lots of control, they can
use the {{cordova.logger}} object.
> Logging levels
> --------------
>
> Key: CB-611
> URL: https://issues.apache.org/jira/browse/CB-611
> Project: Apache Callback
> Issue Type: Improvement
> Components: iOS
> Affects Versions: Master
> Environment: Run Cordova/PhoneGap with Cordova-SQLitePlugin and some
> other plugins
> Reporter: Chris Brody
> Assignee: Shazron Abdullah
> Fix For: Master
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I got a pull request on my Cordova-SQLitePlugin with a special logging
> function that is only logging when built as a debug version. I believe this
> issue should be solved in the core with a log function that is only logging
> when built as a debug version. Ideally a logging facility with multiple log
> levels. Please forgive me if this has already been done somewhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
