[stringtemplate-interest] Group Syntax extension for ModelAdapter and Renderer

[Sam Harwell]

This is an interesting problem. Normally when things are inherited, they
start at the imported group and propagate to the group that imported them.
In this case, it sounds like you want to propagate it from the topmost group
to all the groups it imports.

 

Perhaps the thing to do here is propagate renderers to groups imported with
STGroup.importTemplates(Token) (those are the ones imported via the group
file), but don't propagate them to groups imported with a direct call to
importTemplates(STGroup)?

 

If you look at the diff of TemplateGroup.cs in CL8734 (it's a small diff),
you can see how I adjusted the import code to handle the unload() method in
everyone's cases. If the java code is adjusted in the same way (I can make
the change if you want), then it's easy to propagate renderers by the
following two rules:

 

1.       When STGroup.importTemplates(Token) is called, the current group's
renderers are added to the group that just got imported. This handles the
case where the renderer is registered before the group is imported
(especially relevant in reloading a group file after calling unload()).

2.       When a renderer is added to a group, it is automatically added (by
calling registerRenderer) to all groups in the importsToClearOnUnload list.
This handles the case where the group is imported before the renderer is
registered.

 

Sam

 

From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: Thursday, June 23, 2011 1:44 PM
To: Udo Borkowski
Cc: stringtemplate-interest Template
Subject: Re: [stringtemplate-interest] Group Syntax extension for
ModelAdapter and Renderer

 

I think that we should probably keep this at the programming level.   should
we make renderers inherited instead to solve your problem?

 

Ter

On Jun 21, 2011, at 1:17 AM, Udo Borkowski wrote:





Hi,

 

currently we programmatically register ModelAdapters and Renderers to an
STGroup.

 

What about providing an extension to the syntax of Group to also define
these in a Group file?

 

E.g. I could imagine to use something like

 

adapter "org.w3c.dom.Node"
"com.collinfagan.strum.adapters.xml.NodeModelAdapter"

renderer "org.w3c.dom.Node"
"com.collinfagan.strum.adapters.xml.NodeRenderer"

 

at the top of an Group file. This would mean the same as running this Java
code for the group:

 

group.registerRenderer(org.w3c.dom.Node.class, new
com.collinfagan.strum.adapters.xml.NodeRenderer()); 

group.registerModelAdaptor(org.w3c.dom.Node.class, new
com.collinfagan.strum.adapters.xml.NodeModelAdapter()); 

 

Especially when importing groups this feature comes in handy as I cannot
register adapters/renderers when importing. In these cases I must rely on
the root group. For this group R we must register ALL adapters/renders used
in ANY group R imports. This make things hard to maintain as using a "new"
renderer in some template T requires me to add the "registerRenderer" in
EVERY code using T, maybe indirectly through imports.

 

Similar to features discussed earlier this feature is easy to implement for
the STGroupFile, but the STGroupDir currently has no proper place to hold
this information. So we may also need to tackle this re-appearing topic,
too.

 

 

What do others think?

 

Udo

 

_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest at antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20110623/7889cd92/attachment.html