OSS: Code Generation for the Rails Generation

Written on 7:31:00 PM by S. Potter

As a Rails developer I have become very accustomed to and depend on it's code generator and third party generators that are available to automate development tasks. I like the way the Rails generator is designed, however, it is highly coupled with the Rails framework, so if you want to use the generator for other Ruby (or other language) projects that are not web services/web applications, then it isn't very useful. Another area that the Rails generator has room for improvement is to support metamodels to pass into generator templates. Today I felt the need to create a Rails generator-compliant code generation toolkit into my own OSS project that can be used in any Ruby, Java, C++, Python or other projects that are not pinned to the Rails environment. Today CodeGenie was born! I have started working on the first set of user stories, which includes the following:

  • Run Developer: execute script that generates code as per plugin and metamodel passed in as arguments.
  • Run Developer: execute script that removes previously generated code files as per plugin and metamodel passed in as arguments
  • Run Developer: execute script that updates previously generated code files as per plugin and metamodel passed in as arguments
  • Plugin Developer: Rails generator compliance [Rails generator drop-ins]
The initial metamodel format I will support in CodeGenie will be YAML. After that I will focus on working on more standards based metamodel formats like MOF, UML and XML Schema. Three years ago I worked on a very heavy model-driven architecture (MDA) project where we determined around 95-98% of the [C++] code was generated from a UML metamodel. Since nobody really likes writing boilerplate C++ code, we wrote a code generation toolkit in Python that read in MOF, UML and XML schema metamodel representations and passed in-memory metamodels (built from those formats) to our code templates, which produced the vast majority of our server logic (C++ and Python), server/client stubs + client APIs (in Java, C++, Python, C#) and .NET user-interface forms in C#. At the time I had some (and still do) major grievances about the way we bastardized Rational Rose 2002 MDL file with UML properties to attempt to support the 33% of the UML 1.4 standard that Rational seemed to have forgotten about when writing Rose 2002 and 2003. This is more of a tool issue rather than the way we did code generation, so I will not worry about this in the development of CodeGenie as common sense should dictate to you what metamodel format(s) and CASE tool(s) make sense for your development environment and CodeGenie plugins. My experiences above contribute to why I want to make CodeGenie completely independent of CASE tools and only provide support for standards-based formats. I don't consider Rose's MDL format standards-based (sorry Dean).

If you enjoyed this post Subscribe to our feed

No Comment

Post a Comment