89 lines
3.4 KiB
XML
89 lines
3.4 KiB
XML
|
<chapter id="bml.flags">
|
||
|
|
<title>BML Block Types</title>
|
||
|
|
<para>
|
||
|
|
This documents the flags in braces at the beginning of <filename>.look</filename> file block template definitions.
|
||
|
|
The flags fall into one of three classes:
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
<variablelist>
|
||
|
|
<title>Varible definition types:</title>
|
||
|
|
<varlistentry>
|
||
|
|
<term>F</term>
|
||
|
|
<listitem>
|
||
|
|
<para>Full, mix of multi & single line property definitions:
|
||
|
|
<programlisting><![CDATA[<?template
|
||
|
|
foo<=
|
||
|
|
Multi
|
||
|
|
line
|
||
|
|
string
|
||
|
|
<=foo
|
||
|
|
bar=>Single line string
|
||
|
|
template?>]]></programlisting>
|
||
|
|
</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
<varlistentry>
|
||
|
|
<term>P</term>
|
||
|
|
<listitem>
|
||
|
|
<para>Pipe delimited, properites are named DATA<n>, where <n> starts at 1 and increases.
|
||
|
|
<programlisting><?template DATA1|second arg|DATA3 template?></programlisting>
|
||
|
|
</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
<varlistentry>
|
||
|
|
<term>D</term>
|
||
|
|
<listitem>
|
||
|
|
<para>One property, and it's named DATA
|
||
|
|
<programlisting><?template I am the DATA template?></programlisting>
|
||
|
|
</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
</variablelist>
|
||
|
|
<variablelist>
|
||
|
|
<title>Static template definitions:</title>
|
||
|
|
<varlistentry>
|
||
|
|
<term>S</term>
|
||
|
|
<listitem>
|
||
|
|
<para>Static: output won't have more BML to expand, or properties to fill-in, so don't try.</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
<varlistentry>
|
||
|
|
<term>R</term>
|
||
|
|
<listitem>
|
||
|
|
<para>Less static: add pRoperties, but then don't BML expand.</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
</variablelist>
|
||
|
|
<variablelist>
|
||
|
|
<title>Controlling expansion vs. interpolation order:</title>
|
||
|
|
<varlistentry>
|
||
|
|
<term>p</term>
|
||
|
|
<listitem>
|
||
|
|
<para>
|
||
|
|
Pre-parsed.
|
||
|
|
BML-expand parameters first, then interpolate into template.
|
||
|
|
By default, parameters are interpolated first, then everything is expanded.
|
||
|
|
But if you use <literal>%%TITLE%%</literal> twice in your <literal>PAGE</literal>, for example, and your <filename>.bml</filename> file defines <literal>TITLE=></literal> with a <literal>_CODE</literal> block, it will be run twice, so it's generally a good idea to make <literal>PAGE</literal> definitions pre-parsed.
|
||
|
|
Also, then, you avoid re-running most of your output through the BML expander a second time.
|
||
|
|
</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
<varlistentry>
|
||
|
|
<term>s</term>
|
||
|
|
<listitem>
|
||
|
|
<para>
|
||
|
|
Expand embedded parameterless static blocks in definition early.
|
||
|
|
When the template file is read, any blocks of the form <literal><?foo?></literal> are expanded ahead of time.
|
||
|
|
Useful in conjunction with the <literal>{S}</literal> flag. consider:
|
||
|
|
<programlisting><![CDATA[# Our image server:
|
||
|
|
IMGPREFIX=>{S}http://www.site.com:8080/
|
||
|
|
|
||
|
|
# Some block that has an image:
|
||
|
|
SPACER=>{Ss}<img src='<?imgprefix?>/spacer.gif' width='1' height='10'>]]></programlisting>
|
||
|
|
The <literal>SPACER</literal> block isn't really static, but because <literal>{s}</literal> is used and <literal><?IMGPREFIX?></literal> is static, then <literal>SPACER</literal> can also be static.
|
||
|
|
</para>
|
||
|
|
</listitem>
|
||
|
|
</varlistentry>
|
||
|
|
</variablelist>
|
||
|
|
</para>
|
||
|
|
</chapter>
|