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

[Sam Barnett-Cormack]

Sorry to top-post, but this is a very general statement/opinion...

Renderers and ModelAdapters need to be entirely in the programming side, 
surely, to keep the complete language-agnostic value of template code. 
Unlike Antlr grammars, for instance, there's nothing in a StringTemplate 
that is ever language-specific (in terms of implementation), that I'm 
aware of, and I devoutly hope it will remain so.

Furthermore, whether it happens at the programming level or in the group 
file (and what about people not using group files, but group dirs or a 
custom group type), whatever is chosen in terms of when to propagate and 
in which direction, there will always be situations where what happens 
isn't what makes sense for that use-case. Thus, what would really be 
ideal is a way of controlling it more finely, as to when it propagates 
or doesn't, some sort of configuration. This would, however, likely be a 
huge burden on the ST developers, and a pretty big burden on those using it.

One alternative that occurs to me as probably working in most cases, is 
to allow a VM-wide setting of model adapters and renderers, and then 
allow group-specific overriding of this. Whether the group-specific ones 
then propagate or not, and in which direction, I'm not sure. You 
obviously can't have them propagating in both directions without every 
change always affecting the whole constellation of groups involved, 
which would seem suboptimal to me.

Anyway, that's just some software engineering thoughts. To get a better 
decision, it would really make sense to drill down to some competing 
use-cases and see if there's a common denominator that would work in all 
cases that anyone can think of.

Sam

On 24/06/2011 10:41, Udo Borkowski wrote:
> The "propagation" approach solves one half of the problem: with this
> approach one could use renderers and adapters in groups that are
> imported through the "import" statement (and not programmatically). This
> is currently not possible.
>
> But the other half of the problem still exists: assume I change a group
> G and use some special renderer in the new version. The group G is
> imported by many other groups (maybe indirectly). I now need to find all
> the "roots" of imports to G and add the new renderer there. This can
> really become a maintenance nightmare. Providing the "renderer" syntax
> extension and defining the renderer in the group text would solve this
> issue.
>
> Regarding the implementation of the "propagation" approach: registering
> a renderer will require to visit all directly and indirectly imported
> groups and add the renderer to all of them, possibly creating new maps
> etc.. Most of the times this will be extra work as the imported groups
> don't reference that renderer. Propagating a renderer to all imported
> groups may lead to a performance issue when using large systems.
>
> I would also hesitate to use the "propagation" approach as it adds a new
> concept to StringTemplate ("propagation of renderers") that in addition
> seems to "reverse" an already existing concept ("inheritance"). I guess
> this may to misunderstandings.
>
> In contrast to this the "renderer" syntax extension does not use a new
> concept but rather makes an existing feature ("registerRenderer")
> accessible to those users who prefer to work on the group text than
> coding in Java.
>
> As the "propagation" approach does not solve the whole problem I still
> think we should add the "renderer"/"adapter" feature I suggested.
>
> Udo
>
> P.S.: all stuff mentioned regarding "renderer" also applied "adapter".
>
>
>
> On 23.06.2011, at 23:38, Sam Harwell wrote:
>
>> 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>[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
>> <mailto:stringtemplate-interest at antlr.org>
>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
>
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest