incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Brody (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-611) Logging levels
Date Tue, 01 May 2012 22:40:54 GMT

    [ 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

        

Mime
View raw message