[stringtemplate-interest] Issues with handling refresh interval and group loaders.

[Terence Parr]

On Aug 26, 2008, at 9:03 AM, Richard Martin wrote:
> base - (page outline say)
> sport extends base - (a page replacing regions in base)
> news extends base - (a page replacing regions in base)
>
> So the code rendering the page just calls loadgroup with news or sport
> and then gets the instanceof page, sets the attributes and renders.
> All works good but setting refresh interval to 0 only allows changes
> in "news" to work not it's hierarchy.  So any changes to "base" do not
> appear.  Even if I call getSupergroup on the "news" and sets its
> timeout to 0 I still cant get any changes made to "base" to appear.
> If I explicitly load base and set its timeout to 0 then I can get it
> to accept changes.  But I will not know the specific hierarchies to
> load in all super groups manually and set there timeouts.  Is this a
> bug or a feature I am not using correctly, is it possible to set an
> entire hierarchy refresh interval to 0?

That is weird...So when you create base and the subgroups and set the  
refresh interval to 0 before doing any loading, it still has a problem?

> Second is a feature I am probably not using the way that was expected.
> Basically my system is a web framework, it handles multiple contexts
> and each context has it's own templates.  To try get around naming
> conflicts what I did was cache a group loader for each context.  Then
> when my string template controller is asked to render it registers the
> group loader for that context with
> StringTemplateGroup.registerGroupLoader().  Then it calls load group
> with the correct template.  The problem here is if you have two
> contexts that both have a base.stg for example.  Once you goto the
> first context and render is called everything works fine, you get the
> templates for that context.  Then you goto another context that has a
> base.stg, the correct group loader is registered and the group is
> loaded from it.  The problem there is you get the base.stg from the
> first context even though you are on a different group loader, but if
> the other templates don't clash by name you get the correct other
> parts.  I am guessing that this is an artifact of the caching problem
> above.  Base has been cached regardless of the registered group
> loader.  So even though I have changed the group loader the call for
> base.stg is returning the cached version.
> Has it ever been considered that you might need a way to load multiple
> distinct sets of templates (that may contain naming conflicts), or is
> there another way to work around it?

ST was specifically designed to handle this. that is the point of the  
group mechanism. jGuru did this all the time. A new skin for the site  
was simply a new ST group. From the session, I find the skin name and  
then switch the templateLib pointer in my framework to the appropriate  
ST gropu object. works like a charm including inheritance.

Ter