zlax/ljr
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

init

Browse Source
This commit is contained in:
ivan
2019-02-06 00:49:12 +03:00
commit 8dbb1bb605
4796 changed files with 506072 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
livejournal/doc/raw/ljp.book/bml/core.xml Executable file
View File

@@ -0,0 +1,36 @@
<chapter id="ljp.bml.core">
<chapterinfo>
<title>Core <abbrev>BML</abbrev> blocks</title>
</chapterinfo>
<title>Core <abbrev>BML</abbrev> blocks</title>
<para>
Core blocks are predefined blocks that are named with a leading underscore.
Most core blocks have a higher purpose than simple template use:
</para>
<variablelist>
<varlistentry>
<term><literal role="core.bml.block">_code</literal></term>
<listitem><para>
<literal>&lt;?_code _code?&gt;</literal> blocks are perhaps the most useful feature of
<abbrev>BML</abbrev> outside of the ability to have global site templates.
These blocks allow template authors to embed pieces of executable Perl code
within the bml page that get executed on the server.
</para><para>
</para><para>
The code you write gets executed in its own package (namespace) called
<computeroutput>BMLCodeBlock::</computeroutput>.
Any variables you declare in one code block on a page without using
<literal>my</literal> are carried on to the next <literal>_code</literal> block.
</para><para>
Because the BML parser must evaluate everything on the page before sending the
<abbrev>HTTP</abbrev> headers, make sure you don't print anything.
Any output printed to <literal>STDOUT</literal> will just be interpreted as
<abbrev>HTTP</abbrev> headers. How the <literal>_code</literal> blocks work is
that you need to return a value at the end.
Whatever value your code fragment returns is what the block evaluates to.
Usually what you end up doing is building a string, concatenating things to it
over and over, and then returning it at the end.
</para></listitem>
</varlistentry>
</variablelist>
</chapter>

89
livejournal/doc/raw/ljp.book/bml/flags.xml Executable file
View File

@@ -0,0 +1,89 @@
<chapter id="ljp.bml.flags">
<title>Template Flags Explained</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 &amp; 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&lt;n&gt;, where &lt;n&gt; starts at 1 and increases.
<programlisting>&lt;?template DATA1|second arg|DATA3 template?&gt;</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>D</term>
<listitem>
<para>One proprety, and it's named DATA
<programlisting>&lt;?template I am the DATA template?&gt;</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>&lt;?foo?&gt;</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>

21
livejournal/doc/raw/ljp.book/bml/index.xml Executable file
View File

@@ -0,0 +1,21 @@
<part id="ljp.bml.index">
<partinfo>
<title>The Better Markup Language</title>
<titleabbrev><abbrev>BML</abbrev></titleabbrev>
</partinfo>
<title>The Better Markup Language</title>
<titleabbrev><abbrev>BML</abbrev></titleabbrev>
<partintro>
<para>
<abbrev>BML</abbrev> is a server-side markup language that lets you define your own
<abbrev>BML</abbrev> blocks and use them as templates within your <abbrev>BML</abbrev> pages.
Your templates don't even have to be static. Because <abbrev>BML</abbrev> pages are
converted to <abbrev>HTML</abbrev> on the server when users request them, this also
enables you to embed live code within your <abbrev>BML</abbrev> pages, just like a
<abbrev>CGI</abbrev> script.
</para>
</partintro>
&ljp.bml.flags;
&ljp.bml.core;
&ljp.bml.api.ref;
</part>