Braces (LaTeX templates doable?)
Martin Läuter
Soon after the ctemplate project came out I made my own Java
version, not knowing Hapax being around -- sorry. With the project at
my disposal I have been formatting many and large documents, once
being accustomed to the template filling code.
My Java templates sport an additional first line where marker
delimiters (here the double braces) and user definable tags are put,
delimited by spaces.
What can this be useful for? Alternative marker delimiters make the
template library available to (La)TeX users or other programs that use
braces for their own purposes (and may run in double braces very
easily). Tags label the specific template file, so if you are using
the same template filling code for different output formats
(=different template files), you can get information what kind of
format is on just now. I use it to deliver different date formats in
RSS and Atom feeds.
And last, I found it very useful being able to specify 'separator
text' for sections. That is text inserted between all instantiations
of sections. It is easy to put additional text into sections, but to
erase it from beginning of the first (or end of last, resp.)
instantiation, that took an additional section.
Do you find these features useful? Are configurable marker delimiters
(on template basis) doable? How about LaTeX escapes?
Regards,
Martin.
Craig Silverstein
} (La)TeX users or other programs that use braces for their own
} purposes (and may run in double braces very easily).
Funny, I was just thinking about this the other day. I had managed to
convince myself that double-braces don't really appear in practice in
many contexts, though, so it wasn't really necessary to support. But
latex is a good point; I had forgotten about it.
My plan at the time was to think about introducing a new built-in
variable, BI_2B or some such, that evaluates to "{{". How messy would
that be for latex? Probably pretty messy.
The idea of specifying alternative delimiters on a per-template basis
makes sense to me. What do folks think of the following syntax?
{{=AAA BBB=}}
This says, 'replace {{ and }} with AAA and BBB'. We can either
require this to be first thing in the file, or just allow it wherever,
and have it apply to all subsequent text. I like the latter if the
implementation isn't too annoying. So you could do
{{=<< >>=}} I need {{ but can use <<MARKUP>> markup anyway.
<<={{ }}=>> {{! back to normal! }}
AAA and BBB can be any characters except for whitespace, :, and =.
They can be the equal too:
{{=| |=}} I need {{ but can use |MARKUP| markup anyway.
|={{ }}=| {{! back to normal! }}
} Tags label the specific template file, so if you are using the same
} template filling code for different output formats (=different
} template files), you can get information what kind of format is on
} just now. I use it to deliver different date formats in RSS and Atom
} feeds.
I'm not sure I understand this suggestion. Can you give a specific
example?
} And last, I found it very useful being able to specify 'separator
} text' for sections.
Yes, I can see how this would be very useful. It seems like common
functionality, and annoying to work around. What API did you use? Do
you specify the separator text inside the template, or on the C (Java)
side via a sectionSeparator() function call or some such?
craig
Martin Läuter
> variable, BI_2B or some such, that evaluates to "{{". How messy would
> that be for latex? Probably pretty messy.
>
> The idea of specifying alternative delimiters on a per-template basis
> makes sense to me. What do folks think of the following syntax?
> {{=AAA BBB=}}
would chain template file and template filling programs fixed together
-- and to be synchronized. The implementation of Expand() will have to
cope with nested templates using different delimiters -- but hey, it's
just a program!
> } Tags label the specific template file, so if you are using the same
> } template filling code for different output formats (=different
> } template files), you can get information what kind of format is on
> } just now. I use it to deliver different date formats in RSS and Atom
> } feeds.
>
> I'm not sure I understand this suggestion. Can you give a specific
> example?
{{ }} XML RSS
compared to the Atom template file first line
{{ }} XML ATOM
. The template filling code asks the template object for tags and
decides for the date format:
if(template.hasTag("RSS")) {
dict.addStringValue("DATE",rssdf.format(art.getTime()));
} else if(template.hasTag("ATOM")) {
dict.addStringValue("DATE",atomdf.format(art.getTime()));
} else {
dict.addStringValue("DATE",normaldf.format(art.getTime()));
}
I see difficulties when it comes to nested templates, though --
combine tag sets or just take the innermost tag set? When combining,
must we think of negative tags (erase possible present tags)?
> } And last, I found it very useful being able to specify 'separator
> } text' for sections.
>
> Yes, I can see how this would be very useful. It seems like common
> functionality, and annoying to work around. What API did you use? Do
> you specify the separator text inside the template, or on the C (Java)
> side via a sectionSeparator() function call or some such?
be specified in the template. I abused the filter, which also limits
the possibilities (one might want to use markers in separators, here
only non-: text):
Toys with separating commas: {{#TOYS:sep=, :h}}{{NAME}}
{{/TOYS}}
Greetings,
Martin.
Craig Silverstein
} approach would chain template file and template filling programs
} fixed together -- and to be synchronized.
Actually, BI_2B would be built into the template dictionaries, just
like BI_SPACE etc are now. I don't think using it will be
particularly tricky, it's just a matter of how messy the syntax is.
} My first line for the RSS template file is
} {{ }} XML RSS
} compared to the Atom template file first line
} {{ }} XML ATOM
} . The template filling code asks the template object for tags and
} decides for the date format:
} if(template.hasTag("RSS")) {
} dict.addStringValue("DATE",rssdf.format(art.getTime()));
} else if(template.hasTag("ATOM")) {
} dict.addStringValue("DATE",atomdf.format(art.getTime()));
} else {
} dict.addStringValue("DATE",normaldf.format(art.getTime()));
} }
Yeah, I think the suggested way do to this would be using modifiers.
So your template-filling code would look like this:
dict.addStringValue("DATE", art.getTime());
and your atom template would have text like
{{DATE:x-format-date=atom}
vs rss template which says
{{DATE:x-format-date=rss}
or whatever.
How well would that work for you? We're moving towards a model where
presentation-details like this are specified in the template rather
than the code, so I think this custom modifier approach is nice if it
works.
} Thinking that the separator text is layout language material, it
} must be specified in the template.
Yeah, I agree. Doing it as a modifier is definitely easy!, but you're
right it's limiting in ways that will probably be annoying to someone
in the future. I'll think if there's a clear, more general way to
implement something like this.
craig
Martin Läuter
> } I like the {{=...=}} syntax much better, whereas the variable
> } approach would chain template file and template filling programs
> } fixed together -- and to be synchronized.
harm presentation programs that rely on specific line ends to achieve
some layout.
> Actually, BI_2B would be built into the template dictionaries, just
> like BI_SPACE etc are now. I don't think using it will be
> particularly tricky, it's just a matter of how messy the syntax is.
only variable, we would need (only) BI_1BRACE, at least for
\oneargumentmacro{{{ARG}}}
which would become
\oneargumentmacro{{BI_1BRACE}}{{ARG}}}
and we see how editors that match opening and closing braces would
cough.
> } My first line for the RSS template file is
> } {{ }} XML RSS
> } compared to the Atom template file first line
> } {{ }} XML ATOM
> } . The template filling code asks the template object for tags and
> } decides for the date format:
> } if(template.hasTag("RSS")) {
> } dict.addStringValue("DATE",rssdf.format(art.getTime()));
> } else if(template.hasTag("ATOM")) {
> } dict.addStringValue("DATE",atomdf.format(art.getTime()));
> } else {
> } dict.addStringValue("DATE",normaldf.format(art.getTime()));
> } }
>
> Yeah, I think the suggested way do to this would be using modifiers.
> So your template-filling code would look like this:
> dict.addStringValue("DATE", art.getTime());
>
> and your atom template would have text like
> {{DATE:x-format-date=atom}
> vs rss template which says
> {{DATE:x-format-date=rss}
> or whatever.
somewhere in the library, and one might come up with a very special
and private distinction between different templates, that nobody would
put in the Google library. I must admit that I'm not up to date, maybe
the ctemplate library supports plug-ins that react to modifiers.
Tags would be a way to have the author implement his own needs.
> How well would that work for you? We're moving towards a model where
> presentation-details like this are specified in the template rather
> than the code, so I think this custom modifier approach is nice if it
> works.
to have a presentation programming language. Loops are already there.
Conditionals not yet
<dream mode="on">
{{#TOYS}}
{{?IF:FIRST}}
{{?ELSE}}
{{?IF:LAST}}and {{?ELSE}}, {{?ENDIF}}
{{?ENDIF}}
{{NAME}}
{{/TOYS}}
% For geeks {{?IF:FLAG:3}} to select bits, or for ultra-geeks {{?
IF:FLAG:0x3}} decision by ANDing with given mask.
% One would define fallback FIRST and LAST as 0, and for the first
dictionary add a FIRST value 1, for the last a LAST value 1, that
would not be too much of a memory wastage.
<dream mode="off">
JSP and JSF have tried the separation as well, and it is really
difficult to draw the line. How fat will one become ctemplate?
ENDLESSLOOP, BREAK, CONTINUE? Variables? Just now the structure of the
template dictionary tree follows the needs of the layout engine. How
general/separated would one like to have model structure and layout
structure?
> } Thinking that the separator text is layout language material, it
> } must be specified in the template.
>
> Yeah, I agree. Doing it as a modifier is definitely easy!, but you're
> right it's limiting in ways that will probably be annoying to someone
> in the future. I'll think if there's a clear, more general way to
> implement something like this.
Greetings,
Martin.
Craig Silverstein
} only variable, we would need (only) BI_1BRACE, at least for
} \oneargumentmacro{{{ARG}}}
} which would become
} \oneargumentmacro{{BI_1BRACE}}{{ARG}}}
} and we see how editors that match opening and closing braces would
} cough.
That's not true, actually. The template language currently supports
\oneargumentmacro{{{ARG}}}
just fine -- give it a try!
Does that affect how you feel about {{BI_2B}}? It really is the
easiest solution, so if it works for people who need it, I'm very
happy to go that route. :-)
} > and your atom template would have text like
} > {{DATE:x-format-date=atom}
} > vs rss template which says
} > {{DATE:x-format-date=rss}
} > or whatever.
}
} That is surely the right way. But the modifier coding has to be
} somewhere in the library, and one might come up with a very special
} and private distinction between different templates, that nobody would
} put in the Google library.
Again, not really true -- ctemplate supports user-defined modifiers:
You can register a custom modifier with the template system. But
you're right this is a relatively recent addition to the ctemplate
system, so maybe not everyone is familiar with it yet.
} If you want to separate presentation details you would have
} ultimately to have a presentation programming language.
This is an excellent summary of what distinguishes ctemplate from
other temlpate systems: its rejection of this approach. As you point
out, it leads to a slippery slope. What's the point of separating out
temlpates from code if templates just become a new type of code?
While ctemplate has things like variables and loops and even a form of
conditional, they are set up and controlled entirely within the
programming language (c++ in this case), not within the template
markup language. That won't change in ctemplate; for folks who are
looking for that, there are already plenty of template languages with
that model to choose from.
craig