Summary: | Incorrect collection output for Javascript console evaluation | ||
---|---|---|---|
Product: | WebKit | Reporter: | Conrad Taylor <conradwt> |
Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Enhancement | CC: | apavlov, conradwt, me, pmuellr, timothy |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://www.jquery.com |
Description
Conrad Taylor
2009-05-12 04:02:10 PDT
There should be some quick little function you could apply to $('a') to get what you want, you would think (I'm not a jquery expert). Personally, I like the output as is, BUT, it might be nice to filter the properties/indices of the expanded objects to not show functions, not show inherited-from-prototype properties. The jQuery documentation specifies the following: $('a') returns an Array<Element(s)> The documentation can be found here: http://docs.jquery.com/Selectors BTW, there are additional functions that can be applied to the result-set. However, it would be nice to have functionality in a Javascript console that is consistent with the result-set expected from the method that's being invoked. Next, this isn't specific to a particular Javascript library but it has to do with the support of collections as result-set. Finally, I would like to see Javascript console support of collections similar to that of non-collections. By collections, do you mean arrays. As in arrays vs. objects that aren't arrays? It's already a bit difficult to make a determination, at least in user-land JavaScript, whether an object is an array or not. It's difficult to determine the best thing to actually display, in a general sense. What might be interesting to think of is to allow objects returned from frameworks like jQuery to make a determination of how to display themselves. I really like the structured output in the console that Web Inspector applies, but poking through the jQuery output, it's also clear that it's a bit too busy. What if jQuery objects added something like a "web_inspector_console_display" function which, when invoked, rendered output relevant to the console. Might be a string, and then just printed, or maybe it would a DOM tree which would be rendered inline. You could then imagine that folks using jQuery would then be able to further enhance that functionality in some way through new jQuery APIs. In terms of trying to make this browser agnostic, perhaps the relevant property would be named "console_display_result". There's some precedence here from the Smalltalk world; there, some implementations supported specialized output for the debugger via a debugPrintTo:aStream method, implemented on Object, whose implementation was just "self printTo: aStream". Classes could customize what was displayed in debugger single-line views by overriding the method. I like the way we output daya now, and feel the way Firebug dumps everythign as a large string is not as elegant. (In reply to comment #3) > What if jQuery objects added something like a "web_inspector_console_display" > function which, when invoked, rendered output relevant to the console. Might > be a string, and then just printed, or maybe it would a DOM tree which would be > rendered inline. You could then imagine that folks using jQuery would then be > able to further enhance that functionality in some way through new jQuery APIs. > > In terms of trying to make this browser agnostic, perhaps the relevant property > would be named "console_display_result". I can see this being useful. I don't think underscores are a good fit here. Maybe "toConsoleResult" or "toConsoleMessage"? Matching the the "toString" and "toValue" concept. Objective-C also has this with the "description" method. It seems that there are a lot of implementation details that are presented when an array of objects is the result-set. For example, using the google.com: > var links = document.getElementsByTagName( 'a' ) => undefined > links => [object NodeList] > links.length => 30 > links[0] => <a href="http://images.google.com/imghp?hl=en&tab=wi" onclick="gbar.qs(this)" class="gb1">Images</a> Note: The above result-set generates the following: ATTRIBUTE_NODE: 2 CDATA_SECTION_NODE: 4 COMMENT_NODE: 8 DOCUMENT_FRAGMENT_NODE: 11 DOCUMENT_NODE: 9 DOCUMENT_POSITION_CONTAINED_BY: 16 DOCUMENT_POSITION_CONTAINS: 8 DOCUMENT_POSITION_DISCONNECTED: 1 DOCUMENT_POSITION_FOLLOWING: 4 DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC: 32 DOCUMENT_POSITION_PRECEDING: 2 DOCUMENT_TYPE_NODE: 10 ELEMENT_NODE: 1 ENTITY_NODE: 6 ENTITY_REFERENCE_NODE: 5 NOTATION_NODE: 12 PROCESSING_INSTRUCTION_NODE: 7 TEXT_NODE: 3 and so on I'm not sure if the level of detail is really needed but I do agree with some type of message send on the returned object is an excellent idea for writing the object to the output stream. I guess what you're saying would be similar to Ruby's Object#to_s. In any case, I found some interesting Javascript that can add a FireBug console into Webkit here: http://getfirebug.com/lite/Safari.html This is nice but something native within WebKit would be nicer. (In reply to comment #3) > By collections, do you mean arrays. As in arrays vs. objects that aren't > arrays? It's already a bit difficult to make a determination, at least in > user-land JavaScript, whether an object is an array or not. > (Patrick asked for my input, I work on Firebug). This problem is more subtle and complicated than most people realize. Firebug has gone through a number of efforts and our test suite includes array tests for this reason. Given an object one wants to present it to users in a way that is most useful to them: if they think of its as an array, then it should be presented as an array. Unfortunately for us, the set of types which users think of as arrays is not known to us. Oh and we can't read their minds either ;-). Firebug uses a combination of type testing and object property analysis: http://code.google.com/p/fbug/source/browse/branches/firebug1.4/content/firebug/reps.js#448 (The YUI license bit should be removed, the code has long since diverged from them and it was only one function at the time). HTH, jjb This seems to have been fixed a while ago, presumably by pfeldman. On ToT (r66878), for $('a') on jquery.com I get an array: [ <a id="jq-siteLogo" href="http://jquery.com" title="jQuery Home">…</a>, <a href="http://jquery.com/" title="jQuery Home">jQuery</a>, <a href="http://plugins.jquery.com/" title="jQuery Plugins">Plugins</a>, <a href="http://jqueryui.com/" title="jQuery UI">UI</a>, <a href="http://meetups.jquery.com/" title="jQuery Meetups">Meetups</a>, <a href="http://forum.jquery.com/" title="jQuery Forum">Forum</a>, <a href="http://blog.jquery.com/" title="jQuery Blog">Blog</a>, ... ] |