turpid-monkey / modelgen Goto Github PK

Consider the following interfaces:

public class Test {
  // ...
}

and

public class TestObject {
  // ...
}

They will lead to the following impl Classes:

Test               => TestObject.java
TestObject         => TestObjectObject.java

Problem:

TestObject class from Test causes name collision with TestObject interface.

Possible Solution:

Move impl classes to implsubpackage.

The model will be used for representing Java/Groovy code, so a flexible way to generate code from model instances should be provided.

One idea to do so would be to introduce a nested @codegenerators(@code) annotation:

@CodeGenerators(
    @Code(lang="Java", template="java/someType.vm"),
    @Code(lang="C#", template="csharp/someType.vm")
)
interface SomeType {
     String name;
}

The annotations would generate two XyzCodeGenerator classes that would recursively call the declared velocity templates.

Generate code that allows Dejabeans models to be serialized as protobuffers.

• produce a .proto definition for a set of interfaces
• generate serialization code
• tbd: avoid runtime/compile-time dependency on protobuffer libraries/tooling

In the current design templates are not loaded from classpath which causes problems when running from classes which are not part of the modelgen.jar (problem is caused by getResource().getFile()calls).

Instead, the velocity's classpath resource loader should be used.

Possible solution: use full type name instead of short name + import

The current singleton-pattern is not safe:

   public static ModelFactory instance()
   {
      if (instance==null) return instance = new ModelFactory(); else return instance;
   }

Enum-Singleton might be handy:

enum {
  INSTANCE
}

or https://en.wikipedia.org/wiki/Singleton_pattern#cite_note-9

Configuration options:

• Package of model interfaces
• Model interface type names
• Source output folder (default source vs. generated source)

Following requirements should be met for a commands/undo/redo support layer:

• It should be possible to switch usage of commands on or off for an object model or part of it
• Writable interfaces should be used as API

In pseudo-code this could look like follows:

Person p = ModelFactory.createPerson();
CommandSupport cs = new CommandSupport();
EditablePerson p = cs.register(p, EditablePerson.class);
p.setName("Elizabeth");
cs.undoLast();
assert p.getName()==null;
cs.redoLast();
assert p.getName().equals("Elizabeth")

Question: How should the following three cases behave in the generated code?

interface ClassNode {
    @Containement MethodNode getMethodNode();
}
// vs
interface ClassNode {
   Collection<MethodNode> getNodes();
}
// vs
interface ClassNode {
   @Containment Collection<MethodNode> getNodes();
}

Calling

        Model model = new Model();
        model.init(MethodNode.class, ClassNode.class);

with:

public interface ClassNode {
    @Containment MethodNode getMethod();
}

public interface MethodNode extends Contained<ClassNode>{

}

results in:

Exception in thread "main" java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
    at org.mism.modelgen.Property.init(Property.java:31)
    at org.mism.modelgen.Type.initProperties(Type.java:154)
    at org.mism.modelgen.Type.init(Type.java:82)
    at org.mism.modelgen.Model.initType(Model.java:44)
    at org.mism.modelgen.Model.init(Model.java:25)