[
https://issues.apache.org/jira/browse/CB-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266211#comment-13266211
]
Chris Brody commented on CB-611:
--------------------------------
bq. 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?
Both.
bq. 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.
Why restrict the primary use to plugins?
bq. We'll rename the "Debug Console" plugin to "Logger", or whatever.
Sounds better, get rid of the space in the middle.
bq. 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.
Sounds like a good option.
bq. 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.
So you are saying keep {{console}} as-is because it is already a HTML standard
API. Now I get it.
bq. For plugin authors who are doing boat-loads of logging and therefore need
lots of control, they can use the {{cordova.logger}} object.
Unfortunately regular app authors are becoming forced to act as plugin authors
and fixers when they need some native functionality, for which no one has made
the plugin yet, or the relevant plugin does not cover the required
functionality 100%.
I think the real issue and conclusion we are finding is that we *do* have to
make a clean separation between what is HTML compliant in the {{console}}
object and what only works for native in {{cordova.logger}}. It took me until
reading your last comment to understand.
> 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
