make more extendable by allowing to plug-in custom emitters?

[emmanueltouzery]

A colleague of mine opened #22 some time ago. We didn't fix that issue yet but now we're far enough that it's becoming a bigger hindrance and it's again on our radar.
You mentioned solutions (1), (2) and (3).
I now think only (3) is realistic for us, because besides the ng-grid use-case we also internally developed some filter mechanism where the client-side sends to the server a filter specification. That specification also refers to fields in the DTOs in the same way as ng-grid, and we don't intend to change that (it's a different problem than for ng-grid, because our specification is going over the wire to the server).

Also (2) is interesting, but incomplete, for instance we often have specifications like "field1.field2" (with field2 most of the time belongs to another class than field1).

So the ideal solution would be to generate some TS code which would allow us to type something like:

ClassName.field1.get() => "field1"
ClassName.field1.field2.get() => "field1.field2"

I've looked a bit at the code, and I think it would be possible for us to effectively fork typescript-generator-maven-plugin, and when it calls typescript-generator-core, we would paste-in that definition:

typescript-generator/typescript-generator-core/src/main/java/cz/habarta/typescript/generator/TypeScriptGenerator.java

Lines 48 to 52 in a38a6f4

	private void generateTypeScript(Input input, Output output, boolean forceExportKeyword, int initialIndentationLevel) {
	final Model model = getModelParser().parseModel(input.getSourceTypes());
	final TsModel tsModel = getModelCompiler().javaToTypeScript(model);
	getEmitter().emit(tsModel, output.getWriter(), output.getName(), output.shouldCloseWriter(), forceExportKeyword, initialIndentationLevel);
	}

and use the TsModel to generate the TS code that we want, besides calling typescript-generator-core's generator to generate the TSD as usual (I didn't check yet if enough of the classes from the core are really public, but I think they are).

But I don't like forking typescript-generator-maven-plugin, especially because we would probably put our fork on maven-central. So I'm wondering if there is maybe a way to get to the TsModel already now, and achieve our purpose, or maybe such an extension mechanism could be added?

[vojtechhabarta]

Yes, for this case only solution (3) is appropriate.
Now typescript-generator has extension mechanism and can generate also .ts files so I think it should be possible to implement EmitterExtension and generate needed code. Have a look at for example cz.habarta.typescript.generator.ext.EnumConstantsExtension.

The question is what exactly you want to generate. Lets suppose you have two Java classes:

public class ClassA {
    public ClassB field1;
}
public class ClassB {
    public String field2;
}

What TS code would you like to generate for these classes?

[emmanueltouzery]

Firstable, great about the extension mechanism and the example! I'll take a look ASAP!

with regards to the code to generate, you have to keep in mind that while I've read typescript, I've started writing typescript for the first time today :-)

but this compiles and i would have something like that in mind:

// common

class Field {
    name: string;
    parent: Field;
    get: string;

    constructor(name: string, parent: Field) {
        this.name = name;
        this.parent = parent;
        this.get = getName(this);
    }
}

function getName(leaf: Field) : string {
    var result = leaf.name;
    var cur = leaf.parent;
    while (cur != null) {
        result = cur.name + "." + result;
        cur = cur.parent;
    }
    return result;
}

// generated

export namespace ClassB {
    export class Field2 extends Field {
        constructor(parent: Field) {
            super("field2", parent)
        }
    }
    export const field2 : Field2 = new Field2(null);
}

export namespace ClassA {
    export class Field1 extends Field {
        field2: ClassB.Field2 = new ClassB.Field2(this);
        constructor(parent: Field) {
            super("field1", parent);
        }
    };
    export const field1 : Field1 = new Field1(null);
}

// test

console.error(ClassA.field1.get);
console.error(ClassA.field1.field2.get);
console.error(ClassB.field2.get);

although it seems broken at least due to the fact that if I put the ClassA module on top of the ClassB module, I have a crash at runtime. But I'm pretty sure it's solvable. So yes, I don't have the exact idea of what i want generated, but I guess something similar to this. I don't see a strong obstacle to getting it done, but I must try further.

[emmanueltouzery]

I've played enough with the EmitterExtension mechanism at this point to say that I'm pretty sure it allows to do what I would like to do. So, great! Unless I find a blocker on my road now (but I don't think so), I guess we can close this bug, since the typescript-generator extensibility feature is already available.

Except if maybe you'd be interested to add this optional emitter in the typescript-generator repository in case someone else would be interested by it too?

[emmanueltouzery]

FYI I now intend to generate something like that:

// common

class Field {
    name: string;
    parent: Field;

    constructor(name: string, parent: Field) {
        this.name = name;
        this.parent = parent;
    }

    get() : string {
        var result = this.name;
        var cur = this.parent;
        while (cur != null) {
            result = cur.name + "." + result;
            cur = cur.parent;
        }
        return result;
    }
}

// generated

export namespace ClassA {
    export class Field1 extends Field {
        field2: () => ClassB.Field2 = () => new ClassB.Field2(this);
        constructor(parent: Field) {
            super("field1", parent);
        }
    };
    export const field1 : () => Field1 = () => new Field1(null);
}

export namespace ClassB {
    export class Field2 extends Field {
        constructor(parent: Field) {
            super("field2", parent)
        }
    }
    export const field2 : () => Field2 = () => new Field2(null);
}

// test

console.error(ClassA.field1().get());
console.error(ClassA.field1().field2().get());
console.error(ClassB.field2().get());

by using functions instead of fields I get around the declaration order limitation. Very likely this can be made more compact but it'll be good enough for our needs I think (well I guess I could use real functions instead of fields with lambdas but you get the point).

[vojtechhabarta]

I think you can also generate something like this:

// generated by typescript-generator

export interface ClassA {
    field1: ClassB;
}
export interface ClassB {
    field2a: string;
    field2b: ClassB;
    field2c: ClassC;
}
export interface ClassC {
    field3: string;
}

// common part generated by extension

class Fields {
    protected parent: Fields | undefined;
    protected name: string | undefined;
    constructor(parent?: Fields, name?: string) {
        this.parent = parent;
        this.name = name;
    };
    get(): string | undefined {
        if (this.parent && this.parent.get()) {
            return this.name ? this.parent.get() + "." + this.name : this.parent.get();
        } else {
            return this.name;
        }
    }
}

// generated by extension

class ClassAFields extends Fields {
    constructor (parent?: Fields, name?: string) {
        super (parent, name);
    }
    field1 = new ClassBFields(this, "field1");
}
class ClassBFields extends Fields {
    constructor (parent?: Fields, name?: string) {
        super (parent, name);
    }
    field2a = new Fields(this, "field2a");
    field2b = new Fields(this, "field2b");
    field2c = new ClassCFields(this, "field2c");
}
class ClassCFields extends Fields {
    constructor (parent?: Fields, name?: string) {
        super (parent, name);
    }
    field3 = new Fields(this, "field3");
}

export const ClassA = new ClassAFields();
export const ClassB = new ClassBFields();
export const ClassC = new ClassCFields();

// test

console.log(ClassA.field1.get());
console.log(ClassA.field1.field2a.get());
console.log(ClassA.field1.field2b.get());
console.log(ClassA.field1.field2c.get());
console.log(ClassA.field1.field2c.field3.get());
console.log(ClassB.field2a.get());
console.log(ClassB.field2b.get());
console.log(ClassB.field2c.get());
console.log(ClassB.field2c.field3.get());
console.log(ClassC.field3.get());

which doesn't require to repeat field definitions.

I would like to merge this feature if you create extension which generates code you need. It can be useful for somebody else.