support for classes in module return values

[wkeese]

IIUC the plan was that for modules that return a hash containing classes, that all of each class' data will be be shoved into the description of that attribute.

So for example dojox/gfx/shape.js has:

var shape = g.shape = {
    // summary:
    //      This module contains the core graphics Shape API.
    //      Different graphics renderer implementation modules (svg, canvas, vml, silverlight, etc.) extend this
    //      basic api to provide renderer-specific implementations for each shape.
};
...
shape.Rect = declare(shape.Shape, {
    // summary:
    //      a generic rectangle
    constructor: function(rawNode){
        // rawNode: Node
        //      The underlying graphics system object (typically a DOM Node)
        this.shape = g.getDefault("Rect");
        this.rawNode = rawNode;
    },
    getBoundingBox: function(){
        // summary:
        //      returns the bounding box (its shape in this case)
        return this.shape;  // dojox.gfx.Rectangle
    }
});

But there's no real info about Rect in the output file:

<method name="Rect" scope="normal" type="constructor" from="dojox/gfx/shape">
<parameters/>
<return-types/>
</method>

cc @cjolif

[cjolif]

There is similar but slightly different issue in dojox/color/Palette. That modules define the Palette class. On this Palette class it mix-ins a generators property which itself contains several functions: analogous, monochromatic etc... These functions used to be documented in a sub-object of Palette named generators. They are not output in the XML anymore.

[pruzand]

cc @pruzand

[csnover]

Is there any code in the dojo/dijit namespaces that exhibits this sort of behaviour?

[wkeese]

Yes, for example dijit/Tree embeds TreeNode.

[wkeese]

Maybe we should just output the info for dijit/Tree.TreeNode as though it were a module (named dijit/Tree.TreeNode). Then it would display nicely in the viewer.

[cjolif]

That's a reasonable workaround for me. @pruzand would it "fix" the gfx issue as well? I guess yes?

[pruzand]

That's a reasonable workaround for me. @pruzand would it "fix" the gfx issue as well? I guess yes?

I guess so...

Patrick

[cjolif]

@csnover do you think you can make that one for 1.8? Because otherwise gfx doc is pretty much broken. @wkeese did you adopt another strategy for TreeNode?

[wkeese]

I didn't do anything for TreeNode, although it would be easy to split off to a separate file in the tree/ directory.

I still like my previous idea, to treat dijit/Tree.TreeNode as a pseudo-module, although (note to self) that would require updating the hyperlinking code so that dijit/Tree.TreeNode maps to page api/1.8/dijit/Tree.TreeNode rather than api/1.8/dijit/Tree#TreeNode.

[wkeese]

I fixed this with #60, just needs to be merged.

[cjolif]

thanks a lot @wkeese