[
https://issues.apache.org/jira/browse/CB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241213#comment-13241213
]
Patrick Mueller commented on CB-348:
------------------------------------
A somewhat related topic is discussed in
[CB-387|https://issues.apache.org/jira/browse/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: https://issues.apache.org/jira/browse/CB-348
> 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|http://getfirebug.com/wiki/index.php/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 buffered.
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
