[stringtemplate-interest] StringTemplate vs.third-party models

[Rafael Chaves]

Hi,

First time user of StringTemplate here (used several other generators before).

I am very happy with the features of the template language. The
API/implementation could be more flexible though, to help those of us
working with 3rd-party models.

For instance, StringTemplate could allow clients to handle property
value resolution. That way, a client could provide additional
attribute handlers for attributes that are not directly exposed by the
model (but could be easily derived from the model properties). The
built-in reflection-based attribute handler could be just the default
attribute handling mechanism. So would the currently built-in
map-based resolution. But ideally one should be able to chain multiple
attribute handlers, including custom handlers, in a client specified
order. Requiring that we compute all attribute values up-front is far
from ideal for complex third-party models.

Example at hand: I am using ST for generating code from UML models. It
mostly works, except that I need to perform conditional generation
based on model properties that are not always boolean (for instance,
the visibility kind in a UML model can have one of 4 values). If I
could provide a handler for attributes based on name of the
property/type of the target aggregate, I could enhance the base model
with (dynamically computed) boolean attributes just like ST requires
for conditionals. For instance, I could handle implement a "public" or
"isPublic" attribute on UML Property objects that would return true if
the visibility kind is indeed public (and not private, protected or
package-private).

I ended up implementing a hacky mechanism that allows something like
that (see attachment). Basically, it allows you to wrap your root
model object in a read-only map implementation that is backed by the
model object properties, and allows custom property handlers to be
defined. But it only works based on knowledge of the current behavior
of ASTExpr, which is pretty bad. I am not promoting this approach,
just trying to show the extent one has to go to work around the lack
of flexibility in the API.

(BTW, if there is already a way of doing something like this, I will
be really glad to drop this hack!)

Cheers,

Rafael
http://abstratt.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ModelWrapper.java
Type: application/octet-stream
Size: 5732 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20101213/e4f556f6/attachment-0001.obj