Firebug Extensions

[Mike Wilcox]

Submitting a package for dojox.

Dojox.firebugX:

A collection of extras to extend Firebug's capabilities. Includes methods to help improve productivity for large applications involving many developers, and convenience methods to make debugging easier.

Submitted by: Mike Wilcox [email protected]…

[guest]

Test file for firebugX

[Tom Trenka]

Re-assigning to peller for now, see what his opinion is on the topic.

[Adam Peller]

Seems like extensions to an API which was deliberately kept very simple. Are there ways to achieve this without directly impacting the console.* API?

[guest]

There is a purpose behind changing the console API proposal. None of these extensions would be very useful in small apps - they are all designed with a mindset of working with multiple developers on large apps, where the logging gets very unwieldy.

I would consider a new API a possibility. One of my pet peeves with Firebug is typing the word "console" - it does not flow off the keyboard as well as say "dojo.debug" did. So adding tracing to Dojo in the form of dojo.log, dojo.debug, etc., has merit in terms of fixing that little quirk of bad letter arrangement.

However, the main point of the extensions is to reign in a large app with exisiting "console.log's" - turning the console on and off - assigning a log-type to a module - or formatting the pages and pages of logging that run together like lorem ipsum.

Perhaps the extension would be less intrusive if a dojo namespace were used. "dojo.console.enable, dojo.console.margin", etc. But requiring so much typing for a log statement is very counter-intuitive. On the other hand, many of my extension ideas could handle the extra verbosity, as they are used infrequently (as the examples I just listed). That would probably be the best solution for stepping on the fewest api toes.

[Adam Peller]

my vote: 0

[Mike Wilcox]

firebugX file

[Mike Wilcox]

New test file for firebugX

[Mike Wilcox]

Updates to firebugX:

Removed: console.object() - Not as well done as in Firebug Lite. Only minorly useful.

Changed: console.set() to console.customLog() - More descriptive terminology

Added: (see comments for full documentation) console.timeAve() - Averages a series of times console.timeAveEnd() - called once, after a series of timeAve() console.timeGroup() - Holds time() and timeAve() until timeGroupEnd() is called console.timeGroupEnd() - displays all time calls in one place

[Mike Wilcox]

Note the new test file: test_firebugX.html. The previous test file is now invalid. Also note that the path to dojox will need to change in the test file depending on where it is placed. I saw no obvious test staging area for a root level dojox file.

[Adam Peller]

Hi Mike.

That's part of the problem... all dojox projects should be part of a subproject in a folder. At the present time, there are no root level dojox files, by design.

I'm still a big fan of minimalism in console. The explosion of methods concerns me. I wonder why the timeavg APIs, for example, can't be encapsulated in a separate object. It would be a simpler API with less to manage (potentially no string hash/lookups, at least not bound in a global context) less chance of conflicts, and just more explicit.

I understand that it's all there for convenience, but I'd wonder what this API would look like if structured with only the necessary hooks in a top-level object. I know you dread the extra typing, but I'd also rather see this use the namespace conventions (e.g. dojox.debug.console) I don't think it justifies an exception, unless we think these changes ultimately belong in the "real" console.

btw, prototype-like definitions (in the C header sense :) for the purposes of jsdoc can be surrounded by /*===== =====*/ so that they do not occupy any real code space.

[Mike Wilcox]

console with new namespace: dojox.debug.console

[Mike Wilcox]

Extends dojox.debug.console to work with Firebug and Fb Lite

[Mike Wilcox]

Extends dojox.debug.console to work with Safari's Error Console

[Mike Wilcox]

Extends dojox.debug.console to work with Opera's Error Console

[Mike Wilcox]

Changed FirebugX to dojox.debug.console

This could be aliased to something shorter, like var dbg = dojox.debug.console;

Also added extensions, so this can be used in concert with: Firebug, Safari, and Opera. Opera was more of a test case. There are a few IE plugins that I have plans to extend. This way the developer can "opt in" to using this functionality within Firebug.

Peller, if you point me to an example, I'd be happy to comply to the jsdoc spec. It would seem that most (?) of the files are not doing it the way you showed.

And your point taken on minimalism, but I disagree. I've used most of these methods ad hoc in large projects, or seriously wished I would have late into it.

I also don't think Firebug is minimalistic; it's very broad in depth. But it's great design makes it feel minimal.

[Mike Wilcox]

All tests and files. These have a few edits, so they are more up to date.

[Adam Peller]

Mike - FYI, the jsdoc stuff is all allegedly documented in the Dojo Style guide, though I've often had trouble finding what I needed also. You'll find plenty of examples of /*===== in the code if you grep for it. Basically, it makes the structures available to the doc parser without actually taking up space in code on the wire once the build system has a chance to strip out the comments.

As for minimalism, I was thinking mostly about the relatively simple console API, not necessarily Firebug itself. I think there are some cases where you can make your enhancements without adding additional methods or increasing the surface area of console or its dojox cousin -- think state objects. Adding a plugin model sounds as though it takes the complexity of your proposal one level further, but I haven't had a chance to look at that very closely.

[dylan]

Moving to future as this needs to be tested against Firebug 1.2, etc.

It's highly useful in my opinion, so hopefully we can get this in as part of Dojo 1.3.

[ben hockey]

are we still considering these extensions?

if there's no response within 14 days this ticket will automatically close.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!