[Jamon-hackers] Proposed addition

[Ian R. <ian...@gm...>]

Jamon <%method>s are great for providing overridable behavior in a parent
template, but they are limited to content. Sometimes, I want to have data
in my parent template that can be overridden in a child template. There is
a mechanism for doing this in Jamon, but it's clunk. For example, in the
jamon doc project, _Base.jamon contains:

<%class>
  ....
  protected abstract Section currentSection();
</%class>

Then in, for example, Changes.jamon, we have:

<%class>
  @Override protected Section currentSection() { return Section.NEWS; }
</%class>

I'm thinking that this is perhaps more verbose than it needs to be, and is
not friendly to non-java programmers who might want to edit a template. I'm
envisioning something like

Parent.jamon:
<%absparam currentSection>Section currentSection</%absParam>
or
<%param currentSection>Section currentSection = Section.DEFAULT</%param>

Child.jamon
<%overrideParam currentSection>Section.NEWS</%overrideParam>

These would translate under the covers to final variables set on
construction, much like args. The difference is that rather than the
arguments provided from the template caller, they are specified in the
template itself.

The syntax and names above are just a first stab. I've chosen the name
param to evoke the notion of a parameterized template. I've also chosen to
declare each parameter separately (like we do methods), rather than all
together (like we do args). I don't feel strongly about any of these
choices.

Of course, one way to mimic this behavior today is with arguments having
default values. However, this is suboptimal in at least two ways. One is
that there is no way to declare an argument as "abstract" - either it has a
default value, or it doesn't. The second deficiency is that ideally, these
parameters shouldn't be exposed to the template caller at all; its an
internal implementation detail.

Thinking about it briefly, I'm not seeing too many deep difficulties with
this. We would need to track the names of parameters along with the names
of args to ensure there aren't any conflicts between the two. Other than
declaring parameters in annotation form under the @Template annotation, the
proxy would be unaffected by parameters. In particular, calling templates
would be unchanged by this.

Thoughts?

  - Ian