38676 2010-05-06 13:09:02 -0700 Web Inspector: make Web Inspector source code more "modular" 2014-12-12 14:08:42 -0800 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 528+ (Nightly build) All All RESOLVED INVALID P2 Normal --- 0 pmuellr webkit-unassigned bweinstein joepeck keishi pfeldman pmuellr rik yurys oldest_to_newest 221905 0 pmuellr 2010-05-06 13:09:02 -0700 Based on Bug 38672, Comment 1. Ideas? 221911 1 pfeldman 2010-05-06 13:19:50 -0700 I'd support the following plan: Create a new front-end-2 folder. Move JavaScript classes from the original folder into this new folder once they conform to the following requirements: - class depends only on classes from front-end-2 - it enumerates its dependencies declaratively, as in closure library or similarly (http://code.google.com/closure/library/samples/notepad.js) - class defines public api using functions not starting with _ - class is "compiler-ready" (i.e. does not mix foo.bar with foo["bar"], etc.). this might require stopping using getters and setters since minifiers / compilers do not support them well. - class belongs to a meaningful namespace (namespace per panel) - there are no dependencies between panel namespaces (i.e. class that belongs to elements panel can not explicitly depend on class that belongs to resources, they should interact using extension points / services / indirections defined by the platform). I might add stuff here... 221916 2 timothy 2010-05-06 13:23:25 -0700 Keeping getters and setters is a hard requirement for me. Why is a compiler needed? Tell the compilers to get with the program. 221917 3 pmuellr 2010-05-06 13:24:35 -0700 One thought I've had is to create a set of functions to make it easier to build our classes. Here's the typical pattern, from ConsolePanel: WebInspector.ConsolePanel = function() { WebInspector.Panel.call(this); } WebInspector.ConsolePanel.prototype = { ... } WebInspector.ConsolePanel.prototype.__proto__ = WebInspector.Panel.prototype; I suspect we could create some functions to help with this. They would be useful should something happen like we find we can't use the non-standard __proto__ property in the future. defClass(function ConsolePanel() { $super(this); }) setSuperclass(Panel) defMethod(function someInstanceMethod() { }) defStaticMethod(function someStaticMethod() { }) I've built such things in the past, with a bunch of different shapes. I find these read better than all the boilerplate that folks typically use. I also happen to dislike throwing all the prototype functions inside a literal object, so that you have to deal with commas between elements, etc. 221920 4 timothy 2010-05-06 13:27:06 -0700 Please, no. That is far from the easy to read syntax we have. It is more code/typing too… 221923 5 pmuellr 2010-05-06 13:29:46 -0700 In terms of organizing the existing source files, perhaps looking at CommonJS would be good. There are a small handful of browser-based impls; we could certainly roll our own - getting the basics right isn't a big deal. This will help with the pre-req problem. I think there's probably some overlap between closure and CommonJS require(), but CommonJS is getting a lot of interest at the moment. 221924 6 pfeldman 2010-05-06 13:30:00 -0700 (In reply to comment #2) > Keeping getters and setters is a hard requirement for me. > I know. > Why is a compiler needed? > To minify the code and do the type checking if we get that far. > Tell the compilers to get with the program. Fair enough. (In reply to comment #3) > I've built such things in the past, with a bunch of different shapes. I find > these read better than all the boilerplate that folks typically use. I also > happen to dislike throwing all the prototype functions inside a literal object, > so that you have to deal with commas between elements, etc. Original code reads better for me. That's why I mentioned closure style - it looks pretty much the same way as existing code + provides the tooling you are talking about. But... It is really easy to stuck at this point in the "choosing the right framework" phase, so I'd suggest that we do it step by step, leaving existing code structure in place and fighting dependencies as a start... 221934 7 timothy 2010-05-06 13:39:10 -0700 I'd rather not require a framework. I could agree on a compilier that supported our structure though. 1055092 8 burg 2014-12-12 14:08:42 -0800 Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.