[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