Bug 38676 – Web Inspector: make Web Inspector source code more "modular"

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Patrick Mueller]

Based on Bug 38672, Comment 1.

Ideas?

[Pavel Feldman]

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...

[Timothy Hatcher]

Keeping getters and setters is a hard requirement for me.

Why is a compiler needed?

Tell the compilers to get with the program.

[Patrick Mueller]

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.

[Timothy Hatcher]

Please, no. That is far from the easy to read syntax we have. It is more code/typing too…

[Patrick Mueller]

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.

[Pavel Feldman]

(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...

[Timothy Hatcher]

I'd rather not require a framework. I could agree on a compilier that supported our structure though.

[Brian Burg]

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.