Consider adding a filter option to show only overrides

[brian428]

Currently, if you override behavior in a core Touch/Ext class, the only option is to include overrides as tiny footnotes in the existing docs for the Sencha class. This makes it very difficult to locate or read docs for overridden configs/properties/methods.The additional docs are buried in the (often very long) existing documentation for the original class.

Please add an option to either generate the docs for the overridden class which contain only the overridden behavior, or add an additional filter checkbox to show only overridden behavior (e.g. in addition to the Public, Protected, Private, Inherited, etc. checkboxes).

Developers can spend a great deal of time overriding behavior in Ext and Touch. The docs really need to make it easier to locate or read about these overrides.

[nene]

Are you talking about Ext overrides, created like so:

    Ext.define("MyOverride", {
        override: "Ext.core.Class",
        /** Here we override a method of core Ext class */
        bar: function() {
        }
    });

The terminology is kind'a confusing :(

Support for Ext overrides is very rudimentary indeed. I think a show/hide checkbox for overridden members should be fairly simple to add. I'll have to take a closer look.

[brian428]

Yes, exactly. Right now these are omitted from the generated docs entirely, unless you include the original Sencha class as a source. Then they're included, but only as small footnotes in the usually large doc output of the original class.

Honestly, the best option would be to include the docs for the overrides without even needing to pull in all the original docs. If I'm overriding behavior in a Store, I really don't need to duplicate all the original docs from Store. My team can always go look up the docs for the original class. I need people to be able to see and understand the additional custom behavior, since that's the whole point of overriding the original class.

That said, if a filter to show only override behavior was available, that would be better than nothing. It's still an extra step, and still involves having to pull in the original class's source file, so to me it's not ideal. But as I said, it would be better than nothing in terms of letting people focus on the overridden behavior.

Thanks!

[robertb216]

Brian428 hit it on the head!

We generate documentation just for our code and noticed that any class defined with an override doesn't appear unless you include the original ExtJS class as part of the source files list.

Example of our class definition: Ext.define('MBX.override.form.field.NativeComboBox', { override: 'Ext.form.field.ComboBox', .... // various new/override methods });

Our request is to pass a parameter in the config.json file that creates documentation on any override class just like any extended class. We don't want to include the sencha class in our documentation.

We will look into writing an override to jsducks ourselves, but I think other users would be interested in this option as well.

Thanks.

[davmillar]

Echoing @robertb216 on this request. At the very least, there should be some kind of visual indication in the documentation that the original class wasn't found, while still providing what is there.

[Asuza]

Additionally, when generating the documentation, an override missing its overridden class doesn't even show an Error. It only shows a Warning. If an entire file's documentation is skipped over, it should show an Error for that.

[robertb216]

Great point Asuza ... you only get a warning even with verbose error tracing turned on. Warning: .\mbx\override\form\field\NativeComboBox.js:1: Class Ext.form.field.ComboBox not found