[stringtemplate-interest] Specialised STGroup Implementation

Sam Barnett-Cormack s.barnett-cormack at lancaster.ac.uk
Mon Jun 27 08:48:31 PDT 2011


Hi all,

So, after describing my needs and ideas really vaguely before, the idea 
of a specialised STGroup subclass came up. I think I've got my head 
around how this would work, but before I start actually implementing it, 
I want to check whether some aspects of the plan are actually possible.

Firstly, I want to use a (sort-of) different lookup scheme - I want 
template names to be hierarchical (like with directories), but 
individual templates to specify a wildcard of some sort for any element 
but the first - so templates will have names like such (precise symbol 
used as wildcard will likely have to change, I know): 
/CatA/*/field/*/integer ; when requeting a template instance, or 
referring to a template from within a template, there would (of course) 
be no wildcards.

Dove-tailing with this is the idea that dynamic modules to the 
application could add templates to the group. At its most basic, this 
could be done at application startup, or when otherwise requested, in 
which case a string for the whole group *could* be created, but I'd 
prefer to have some ability to call an add method on the group - my 
perusal of the source indicates the methods STGroup.defineTemplate(*), 
though all but one of them are noted in comments as being for testing - 
is the one that isn't (being defineTemplate(String 
fullyQualifiedTemplateName, Token nameT, List<FormalArgument> args, 
String template, Token templateToken)) actually of general utility? I 
understand the purpose of the arguments (I think) except the two 
instances of Token. This could then be used other than on specific 
occaisions, although thread synchronisation would be harder in that case 
- hoping to use the almost-automatic locking mechanics of Java EE in the 
end.

I'm expecting that imcluded groups will work on whatever basis they 
themselves use, so a flat-file group could be included for utility purposes.

I'm also intending that, if multiple modules define identically-named 
templates, I'll be able to just make it predictably use either the first 
one defined or the last one defined (not sure which yet). I may make it 
so that the templates provided by modules are actually done in the form 
of groups that can then be included, so ones that are added to the 
'core' group will always take precedence, and then have some other rule 
for a name being re-used in the core group.

So, apart from being insane, does anyone have thoughts? Is what I'm 
describing (or any particular variant of it) possible? What methods need 
to be implemented or overriden in STGroup to do the sort of thing I'm 
describing? Is it sensible to reuse the directory-hierarchy symbol ('/') 
for my hierarchy, or would it be better to use some other symbol 
arbitrarily? For the purposes of referring inside a template, what 
characters are valid for template names? Is there any reason (when 
adding a template to a group) to restrict the lookup name for the 
template itself to the same characters? My glance at the grammars 
suggests that IDs have to be the tradition mix of letters and 
underscores, and that would (I assume) apply to references within a 
template to another template (except '/' is obviously allowed, binding 
several of those together), but if the name is being provided 
dynamically in code (rather than read from a file), would it be 
restricted similarly? If it's all as restricted as it could possibly be, 
there's still ways around it, but I thought I'd check, as it'd be better 
to have (for instance) the wildcard being some character, rather than 
the absence of any character between separators.

Finally: no, really, is this insane?

Sam


More information about the stringtemplate-interest mailing list