Wednesday, February 22, 2006
 

Ruby, Rails and DSLs

Recently I have been looking to the Ruby on Rails framework.
I am not currently working on the kind of web application Rails
is suitable for, so I have no concrete use for the technology.
However, I think it's really a nice tool and it *does* show you
how simple web applications can be. Java EE *is* overly complicated.

What I find even more interesting is the Ruby language itself and
what you can do with it, especially with regards to building DSLs.
Take a look at typical Rails code: it looks much more like declarative
programming, or said differently, Rails comes close to a DSL for
building web apps, not "just" a framework.

For example, you can write the following code:

class Part < ActiveRecord::Base
  belongs_to :whole
end

This piece of code defines a model class (model in the sense
of MVC) called part. It is made persistent by the ActiveRecord
framework. To enable this functionality, you have to extend from
the ActiveRecord::Base class. So far so good. The interesting thing
is the belongs_to statement. What does this to?

It's purpose is easily explained. It states that this class (Part)
belongs to (i.e. is a part of) the Whole class (that class has to be
defined somewhere ... I don't show it here).

What happens technically is quite interesting. The belongs_to statement
is actually a method call. An alternative notation is as follows:

class Part < ActiveRecord::Base
  belongs_to( "whole" )
end

So, as a part of the class definition, you call a method? Yes,
that's actually possible. Where does it come from? It is defined
as a class method (static, for Java folks) in the Base class from
which we inherit. So the extension mechanism makes the class methods
available in the super class accessible to the currentl class
definition.

But it's even more interesting what happens inside the method.
The belongs_to method adds additional methods to the current
class! The implementation of the belong_to method calls the
define_method operation, which is a kind of "meta method" that
you can use to dynamically modify the program you're currently
writing. So, belong_to adds the following methods:

whole returns the whole to which this part belongs
whole=(whole) assigns this part to a new whole
whole.nil? is a whole assigned?
etc. etc.

So why is this important? It is important because you can use
the belongs_to just like a declaration. It looks as if it were
part of the Ruby language. Compare these two lines of code:

class Part
belongs_to :whole

The first line is core syntax of Ruby. The second line calls
an application defined method. However, the two lines look quite alike.
This means that you can basically define your own syntactical
elements. And *that* means, you can nicely build DSLs by "extending"
the Ruby language. Instead of generating code (using an external
code generator) you use Ruby's reflection mechanisms mechanisms to
do all that dynamically.

Nice.
 
Sunday, February 12, 2006
 

Aspect Oriented Code Generation in oAW 4

I have for a long time advocated the combination of model-driven
and aspect oriented approaches to software development. FOr example,
in my patterns paper on this topic I have shown an approach of using
AO techniques on the level of code generation templates. As of version
4, the openArchitectureWare MDSD framework now supports aspects on
code generation templates.

Assume you have a code generation template that generates some
kind of implementation code for a data entity:


«DEFINE Entity FOR data::Entity»
  «FILE baseClassFileName() »
    public abstract class «baseClassName()» {
      «EXPAND Impl»
    }
  «ENDFILE»
«ENDDEFINE»


«DEFINE Impl FOR data::Entity»
  «EXPAND GettersAndSetters»
«ENDDEFINE»


Now assume, that from somewhere else (we call this a different
cartridge, or generator module) you want to add additional code
to the body of the generated class, after the getters and setters ...
and all of this without modifying the original generator templates.

Here's what you can do in oAW 4. The example adds "meta information" to the
generated class (just an example ...).


«AROUND Impl FOR data::Entity»
  «targetDef.proceed()»
  «FOREACH attribute AS a»
    public static final AttrInfo «a.name»Info =
      new AttrInfo( "«a.name»", «a.type».class );
  «ENDFOREACH»
«ENDAROUND»


Now isn't this cool?

After having this feature in code generation templates, the next step would
be to add this to model-to-model transformations.

Does anybody know anybody who does this already? I would be interested.
 

back to voelter.de

ABOUT ME
This is Markus Voelter's Blog. It is not intended as a replacement for my regular web site, but rather as a companion that contains ideas, thoughts and loose ends.

ARCHIVES
December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 / April 2010 / May 2010 / June 2010 / July 2010 / August 2010 / September 2010 / October 2010 / November 2010 / December 2010 / January 2011 / March 2011 / April 2011 / May 2011 / June 2011 / July 2011 / October 2011 / November 2011 / December 2011 / January 2012 / February 2012 / October 2012 / January 2013 /

FEED
You can get an atom feed for this blog.