[stringtemplate-interest] Embedded loader problems

[Micheal J]

> > Hi,
> >
> > [...]
> >> // before the string template group can be used, the
> static instance
> >> // needs to know which loader to use
> >> 
> StringTemplateGroup.RegisterGroupLoader(embeddedResourceGroupLoader);
> >>
> >> StringTemplateGroup stringTemplateGroup = new StringTemplateGroup(
> >>     WebPageConstant.GROUP_TYPE_NAME,
> >>     embeddedResourceTemplateLoader);
> >>
> >> StringTemplate stringTemplate =
> >>     stringTemplateGroup.LookupTemplate(templateTypeName);
> >
> > I find the static members such as
> > StringTemplateGroup.RegisterGroupLoader()
> > in the ST[#] library to be quite "ugly" actually. And they have
> > implications
> > for use in a _truly_ multi-threaded environment (a real 
> concern now
> > that
> > dual-core and dual-cpu desktops are commonplace).
> 
> correct.  I really hated to do that but I had no other object that
> was managing things.  Your suggestion of a new StringTemplateManager  
> class is probably a good idea.  After discussion, I'm happy to make  
> this change for version 2.3.  Better to do it now than later 
> breaking  
> backward compatibility.
> 
>    The problem here is that we would then need to tell each
> group who  
> manages it, which can cause some of the similar problems  
> That caused  
> me to make a static member.   well, I think anyway.

My original motivation for suggesting the StringTemplateManager was to
minimize the effects of the breaking changes to StringTemplateGroup. That is
to say StringTemplateManager was to be a refactoring/update of
StringTemplateGroup - without static API members - that will eventually
_replace_ StringTemplateGroup. It was to be functionally equivalent to the
current StringTemplateGroup class.

You seem to be suggesting a StringTemplateManager class that manages
StringTemplateGroup instances. I'm not sure that is needed. The current
scheme with two types representing templates (StringTemplate) and template
collection (StringTemplateGroup or perhaps StringTemplateManager in future)
would seem to be sufficient.

One question - that you alluded to - is "what Group/Manager should directly
created StringTemplate instances belong to?". I suggest what we have now - a
"default" Group/Manager exposed as a [private?] static member of
StringTemplateGroup/StringTemplateManager.

> > StringTemplateGroup should really be a self-contained manager for a
> > collection of StringTemplate instances. With support extending the
> > managed
> > domain to include the ST notion of a tree of related  
> > StringTemplateGroups.
> 
> yep.
> 
> > In this scheme, RegisterGroupLoader() et al would be an instance 
> > member on StringTemplateGroup and it's effect would be limited to 
> > the
> particular
> > instance.
> 
>   so would we have to use this new StringTemplateManager thing to
> create new instances of groups?  It could be a very serious 
> change to  
> the functionality.

Well, my proposed StringTemplateManager is functionally equivalent to a
StringTemplateGroup. If we can live with breaking changes to
StringTemplateGroup, we don't need to create StringTemplateManager.

If not, we create StringTemplateManager as a clone of StringTemplateGroup,
make the non-static API changes there and mark StringTemplateGroup as
deprecated. This allows existing apps to run unchanged whilst still allowing
ST to add [more] efficient support for multi-threaded use cases.


Micheal