Re: [gmt-dev] evolving GMT in a fully open process that allowsothers to

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

> > > The dependencies on the target
> > > language (Java in this case) should be kept in template code as far as
> > > possible, rather than in the structure of the model from which you
> > generate.
> >
> > in my view, this does not really work in practice
> > (at least, if you want to keep the template readable).
> > Extending the metamodel with aspects is a good
> > alternative.
>
> I agree to this. And it is not only to keep the template readable. How
else
> would you specify that a certain attribute that is a date in your model
has
> to be implemented as a unix timestamp so that it looks like an INT to the
> database, or a certain relationship in the model as a Java HashMap?

If we're all talking about doing it properly as aspects then we're on the
same page.

This means there's *exactly* one place where I specify
"attribute of type date in model" => "timestamp in unix"

and *exactly* one place  where I specify
"attribute of type date in model"=> "INT in database" etc.

I.e. in my domain-specific model I only specify
"attribute name: blah, attribute type: date", without polluting it with
"timestamp" and "INT".

Alternative: Without good support for aspects you can still achieve the same
effect with an architecture-centric extension of the meta model where
"attribute type" is an explict model element that contains a mapping to a
unix type, SQL type and any further required information. However, your
generated modelling tool will then allow "Joe Programmer" to come along and
define new attribute types that compromise your standardised architecture -
which in turn you can prevent by adding role-based access control to the
generated modelling tool(s) ;-)

Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534