Opened 13 years ago
Closed 9 years ago
#5403 closed enhancement (invalid)
Firebug Extensions
Reported by: | Mike Wilcox | Owned by: | Mike Wilcox |
---|---|---|---|
Priority: | high | Milestone: | future |
Component: | Dojox | Version: | 1.0 |
Keywords: | debugging firebug firebuglite | Cc: | |
Blocked By: | Blocking: |
Description (last modified by )
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]…
Attachments (8)
Change History (23)
Changed 13 years ago by
Attachment: | test_fb.html added |
---|
comment:1 Changed 13 years ago by
Component: | General → Dojox |
---|---|
Owner: | changed from anonymous to Adam Peller |
Re-assigning to peller for now, see what his opinion is on the topic.
comment:2 Changed 13 years ago by
Milestone: | 1.1 |
---|
Seems like extensions to an API which was deliberately kept very simple. Are there ways to achieve this without directly impacting the console.* API?
comment:3 Changed 13 years ago by
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.
comment:4 Changed 13 years ago by
Milestone: | → 1.2 |
---|
comment:5 Changed 13 years ago by
Cc: | alex added |
---|---|
Description: | modified (diff) |
comment:6 Changed 13 years ago by
Cc: | [email protected]… removed |
---|---|
Owner: | changed from Adam Peller to Tom Trenka |
my vote: 0
comment:7 Changed 13 years ago by
Cc: | alex [email protected]… removed |
---|---|
Reporter: | changed from guest to 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
comment:8 Changed 13 years ago by
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.
comment:9 Changed 13 years ago by
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.
Changed 13 years ago by
Attachment: | console.js added |
---|
console with new namespace: dojox.debug.console
Changed 13 years ago by
Attachment: | firebug-ext.js added |
---|
Extends dojox.debug.console to work with Firebug and Fb Lite
Changed 13 years ago by
Attachment: | safari-ext.js added |
---|
Extends dojox.debug.console to work with Safari's Error Console
Changed 13 years ago by
Attachment: | opera-ext.js added |
---|
Extends dojox.debug.console to work with Opera's Error Console
comment:10 Changed 13 years ago by
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.
Changed 13 years ago by
All tests and files. These have a few edits, so they are more up to date.
comment:11 Changed 13 years ago by
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.
comment:12 Changed 13 years ago by
Owner: | changed from Tom Trenka to Mike Wilcox |
---|
comment:13 Changed 13 years ago by
Milestone: | 1.2 → future |
---|
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.
comment:14 Changed 9 years ago by
Owner: | changed from Mike Wilcox to Mike Wilcox |
---|---|
Status: | new → pending |
are we still considering these extensions?
if there's no response within 14 days this ticket will automatically close.
comment:15 Changed 9 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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!
Test file for firebugX