[stringtemplate-interest] template existence testing

[Zenaan Harkness]

On Mon, Mar 31, 2008 at 09:37:15AM -0700, Terence Parr wrote:
> hi Zenaan you cannot cat major and minor version strings in model and push 
> in.  that is a view issue.

Exactly, which is why I want the view to have some code specialization
which does the cat-ing, and to have that code (ie 'view') specialization
be totally within the view.

The major/minor version numbers is simply the simplest example I have,
to illustrate the need: there are others where I have a specific
template which has "extraCode(Model)" template which has _two_pages_ of
code, which is totally non-generic to my java-lib.stg template group,
but needs to be somewhat generic with respect to my data Model.
This example is a once-off, relating to a specific output view (CLI
options processing boilerplate).

But I have other examples where, for example, I have say 10 attribute
methods, all of which are simple getters, and thus all of which are
easily generically generated by a standard java-lib.stg template, eg:

attGetter(att) ::= "public <att.type> get<att.Jname> () {return <att.name>;}"

However, _one_ of these attributes needs a whole bunch of custom code in
its setter method - much more than a mere concatenation of strings.

> So, have a template called version that you 
> override to be either <major><minor> or just <minor>.  I am rushed so might 
> not be understanding...sorry.

Ahh not to worry, I'll explain again:

As you correctly point out, overriding a template is exactly what I want
to do.

BUT !!  I don't know the name of the template I want to override in
advance ((at least, the view does not know, and the view should not have
any deep knowledge of the data Model, at least as much as possible, and
putting this in the view would cause an explosion of data model
knowledge in the view, where there should be none)),

which is BECAUSE, the name of the template to be overridden will always
be totally arbitrary: today it's attGetter(att) for the "version"
attribute, and another attSetter(att) for the "name" attribute of some
random entity in my model, so I could create two view templates (which
otherwise just call the default attGetter and attSetter bodies
respectively), and these templates might be named attGetterBodyVersion
and attSetterBodyFarmName.

Tomorrow it might be the attSetter(att) for the cowsInPlantation model
attribute, or the wierdVersionParticularity attribute, and all these
random model attributes want to have a bit of view specialization code.

This code cannot be static - it depends on the output language desired
(do I want Java, C# or perl "beans"), and on the input model (eg
<debug(att)> type templates, <className(model)> templates, etc etc which
must of necessity come from the model.

As you can see, not only am I currently caused to put very
model-specific knowledge in my [java|csharp|perl]-lib.stg template
groups, but it would also obviously cause the unnecessary explosion in
number of templates mentioned above.


-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.