[
https://issues.apache.org/jira/browse/CB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489192#comment-13489192
]
Patrick Mueller commented on CB-348:
------------------------------------
I'm not so sure. Why there's a lot of improvement possible from where we
are today, the other issue is that console is just generally wonky
everywhere anyway, even on platforms with "first class support" for it. I
was hoping we'd get some additional feedback over time directing us on the
best course of action here. I think the lack of feedback we've gotten in
general re: console (we've gotten some, but not much) is telling me the
best course of action is to do nothing. :-)
The need for console methods may also be going away as the platforms start
sprouting real debugger.
But I'm game for anything.
> console object improvements
> ---------------------------
>
> Key: CB-348
> URL: https://issues.apache.org/jira/browse/CB-348
> Project: Apache Cordova
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
