incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Mueller (Commented) (JIRA)" <>
Subject [jira] [Commented] (CB-348) console object improvements
Date Thu, 29 Mar 2012 13:40:27 GMT


Patrick Mueller commented on CB-348:

A somewhat related topic is discussed in [CB-387|].
 Namely, how to report errors at a particular point in bootstrapping.  In this case, we may
not have a {{cordova}} object available, the {{console}} object may not be set up, etc.

How this relates is at two-fold:

# We may want to present messages to facilities other than the {{console}}, if it's not actually
available.  For instance {{alert()}} may be available, but not {{console}}.  Or, we might
want to provide a way to add error messages to the DOM in a structured way: look for an element
of class {{cordova-error-list}}, append a {{<li>>}} to it's children, set the {{cordova-error-messages-available}}
class on the {{<body>}} element.  This would allow someone to "embed" error messages
in their app.\\
Note, being overly general with the DOM injection version there, but if we're going to open
this thing up, it would be nice to account for being able to do something like that in the
future.  Not sure there's a pressing need for this today.\\
# We should probably make this "inform the user in the best way" functionality available as
a "plain old script" that we could inject into browser environment, for platforms that do
such injections - like iOS.  Reuse the code.  Totally do-able, folks write "scripts" that
can either be used as modules or treated like plain old scripts, all the time.  See underscore.js.

> console object improvements
> ---------------------------
>                 Key: CB-348
>                 URL:
>             Project: Apache Callback
>          Issue Type: Improvement
>          Components: CordovaJS
>            Reporter: Patrick Mueller
>            Assignee: Patrick Mueller
> There is some room for improvement in the console object we support in Cordova.
> # not all of the common API is supported.  Here is the API as implemented by Firebug,
most of which is also implemented in Web Inspector: [Firebug Console API|].
 An example of the issue with this is that the weinre demo makes use of markTimeline (actually,
that's a WebKit-only console method - I think the only one!).  So the demo dies an early death,
if Cordova's console wins the "overwrite the native" battle.
> \\ \\
> # which naturally leads to the next issue - the console should daisy chain its calls
to the "native" console, if it exists.  An example of this issue is that if you use iWebInspector
on a Cordova app, console logging happens in the Xcode console, not the iWebInspector console.
 I'm fine to have it in both places.
> \\ \\
> # console output operations should "buffer".  An example of this issue is that any console
operations which occur BEFORE deviceReady are passed directly to the bit bucket.  Instead,
we should "buffer" these, and then when deviceReady occurs, the console can dump what it's
> Turns out, I have some of these same issues in weinre, but I don't think we can share
an implementation.  weinre generally just delegates everything to the weinre client - eg,
arguments to console.log() are sent as 'remote objects', whereas in Cordova we actually need
to evaluate them.  The buffering and daisy chaining should be exactly the same, and perhaps
those need to be configured (eg, console.daisyChainNative(false)) - maybe the code or at least
design could be shared there.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message