summaryrefslogtreecommitdiff
path: root/includes/cbt/README
diff options
context:
space:
mode:
Diffstat (limited to 'includes/cbt/README')
-rw-r--r--includes/cbt/README108
1 files changed, 108 insertions, 0 deletions
diff --git a/includes/cbt/README b/includes/cbt/README
new file mode 100644
index 00000000..cffcef2f
--- /dev/null
+++ b/includes/cbt/README
@@ -0,0 +1,108 @@
+Overview
+--------
+
+CBT (callback-based templates) is an experimental system for improving skin
+rendering time in MediaWiki and similar applications. The fundamental concept is
+a template language which contains tags which pull text from PHP callbacks.
+These PHP callbacks do not simply return text, they also return a description of
+the dependencies -- the global data upon which the returned text depends. This
+allows a compiler to produce a template optimised for a certain context. For
+example, a user-dependent template can be produced, with the username replaced
+by static text, as well as all user preference dependent text.
+
+This was an experimental project to prove the concept -- to explore possible
+efficiency gains and techniques. TemplateProcessor was the first element of this
+experiment. It is a class written in PHP which parses a template, and produces
+either an optimised template with dependencies removed, or the output text
+itself. I found that even with a heavily optimised template, this processor was
+not fast enough to match the speed of the original MonoBook.
+
+To improve the efficiency, I wrote TemplateCompiler, which takes a template,
+preferably pre-optimised by TemplateProcessor, and generates PHP code from it.
+The generated code is a single expression, concatenating static text and
+callback results. This approach turned out to be very efficient, making
+significant time savings compared to the original MonoBook.
+
+Despite this success, the code has been shelved for the time being. There were
+a number of unresolved implementation problems, and I felt that there were more
+pressing priorities for MediaWiki development than solving them and bringing
+this module to completion. I also believe that more research is needed into
+other possible template architectures. There is nothing fundamentally wrong with
+the CBT concept, and I would encourage others to continue its development.
+
+The problems I saw were:
+
+* Extensibility. Can non-Wikimedia installations easily extend and modify CBT
+ skins? Patching seems to be necessary, is this acceptable? MediaWiki
+ extensions are another problem. Unless the interfaces allow them to return
+ dependencies, any hooks will have to be marked dynamic and thus inefficient.
+
+* Cache invalidation. This is a simple implementation issue, although it would
+ require extensive modification to the MediaWiki core.
+
+* Syntax. The syntax is minimalistic and easy to parse, but can be quite ugly.
+ Will generations of MediaWiki users curse my name?
+
+* Security. The code produced by TemplateCompiler is best stored in memcached
+ and executed with eval(). This allows anyone with access to the memcached port
+ to run code as the apache user.
+
+
+Template syntax
+---------------
+
+There are two modes: text mode and function mode. The brace characters "{"
+and "}" are the only reserved characters. Either one of them will switch from
+text mode to function mode wherever they appear, no exceptions.
+
+In text mode, all characters are passed through to the output. In function
+mode, text is split into tokens, delimited either by whitespace or by
+matching pairs of braces. The first token is taken to be a function name. The
+other tokens are first processed in function mode themselves, then they are
+passed to the named function as parameters. The return value of the function
+is passed through to the output.
+
+Example:
+ {escape {"hello"}}
+
+First brace switches to function mode. The function name is escape, the first
+and only parameter is {"hello"}. This parameter is executed. The braces around
+the parameter cause the parser to switch to text mode, thus the string "hello",
+including the quotes, is passed back and used as an argument to the escape
+function.
+
+Example:
+ {if title {<h1>{title}</h1>}}
+
+The function name is "if". The first parameter is the result of calling the
+function "title". The second parameter is a level 1 HTML heading containing
+the result of the function "title". "if" is a built-in function which will
+return the second parameter only if the first is non-blank, so the effect of
+this is to return a heading element only if a title exists.
+
+As a shortcut for generation of HTML attributes, if a function mode segment is
+surrounded by double quotes, quote characters in the return value will be
+escaped. This only applies if the quote character immediately precedes the
+opening brace, and immediately follows the closing brace, with no whitespace.
+
+User callback functions are defined by passing a function object to the
+template processor. Function names appearing in the text are first checked
+against built-in function names, then against the method names in the function
+object. The function object forms a sandbox for execution of the template, so
+security-conscious users may wish to avoid including functions that allow
+arbitrary filesystem access or code execution.
+
+The callback function will receive its parameters as strings. If the
+result of the function depends only on the arguments, and certain things
+understood to be "static", such as the source code, then the callback function
+should return a string. If the result depends on other things, then the function
+should call cbt_value() to get a return value:
+
+ return cbt_value( $text, $deps );
+
+where $deps is an array of string tokens, each one naming a dependency. As a
+shortcut, if there is only one dependency, $deps may be a string.
+
+
+---------------------
+Tim Starling 2006