README 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109
  1. Overview
  2. --------
  3. CBT (callback-based templates) is an experimental system for improving skin
  4. rendering time in MediaWiki and similar applications. The fundamental concept is
  5. a template language which contains tags which pull text from PHP callbacks.
  6. These PHP callbacks do not simply return text, they also return a description of
  7. the dependencies -- the global data upon which the returned text depends. This
  8. allows a compiler to produce a template optimised for a certain context. For
  9. example, a user-dependent template can be produced, with the username replaced
  10. by static text, as well as all user preference dependent text.
  11. This was an experimental project to prove the concept -- to explore possible
  12. efficiency gains and techniques. TemplateProcessor was the first element of this
  13. experiment. It is a class written in PHP which parses a template, and produces
  14. either an optimised template with dependencies removed, or the output text
  15. itself. I found that even with a heavily optimised template, this processor was
  16. not fast enough to match the speed of the original MonoBook.
  17. To improve the efficiency, I wrote TemplateCompiler, which takes a template,
  18. preferably pre-optimised by TemplateProcessor, and generates PHP code from it.
  19. The generated code is a single expression, concatenating static text and
  20. callback results. This approach turned out to be very efficient, making
  21. significant time savings compared to the original MonoBook.
  22. Despite this success, the code has been shelved for the time being. There were
  23. a number of unresolved implementation problems, and I felt that there were more
  24. pressing priorities for MediaWiki development than solving them and bringing
  25. this module to completion. I also believe that more research is needed into
  26. other possible template architectures. There is nothing fundamentally wrong with
  27. the CBT concept, and I would encourage others to continue its development.
  28. The problems I saw were:
  29. * Extensibility. Can non-Wikimedia installations easily extend and modify CBT
  30. skins? Patching seems to be necessary, is this acceptable? MediaWiki
  31. extensions are another problem. Unless the interfaces allow them to return
  32. dependencies, any hooks will have to be marked dynamic and thus inefficient.
  33. * Cache invalidation. This is a simple implementation issue, although it would
  34. require extensive modification to the MediaWiki core.
  35. * Syntax. The syntax is minimalistic and easy to parse, but can be quite ugly.
  36. Will generations of MediaWiki users curse my name?
  37. * Security. The code produced by TemplateCompiler is best stored in memcached
  38. and executed with eval(). This allows anyone with access to the memcached port
  39. to run code as the apache user.
  40. Template syntax
  41. ---------------
  42. There are two modes: text mode and function mode. The brace characters "{"
  43. and "}" are the only reserved characters. Either one of them will switch from
  44. text mode to function mode wherever they appear, no exceptions.
  45. In text mode, all characters are passed through to the output. In function
  46. mode, text is split into tokens, delimited either by whitespace or by
  47. matching pairs of braces. The first token is taken to be a function name. The
  48. other tokens are first processed in function mode themselves, then they are
  49. passed to the named function as parameters. The return value of the function
  50. is passed through to the output.
  51. Example:
  52. {escape {"hello"}}
  53. First brace switches to function mode. The function name is escape, the first
  54. and only parameter is {"hello"}. This parameter is executed. The braces around
  55. the parameter cause the parser to switch to text mode, thus the string "hello",
  56. including the quotes, is passed back and used as an argument to the escape
  57. function.
  58. Example:
  59. {if title {<h1>{title}</h1>}}
  60. The function name is "if". The first parameter is the result of calling the
  61. function "title". The second parameter is a level 1 HTML heading containing
  62. the result of the function "title". "if" is a built-in function which will
  63. return the second parameter only if the first is non-blank, so the effect of
  64. this is to return a heading element only if a title exists.
  65. As a shortcut for generation of HTML attributes, if a function mode segment is
  66. surrounded by double quotes, quote characters in the return value will be
  67. escaped. This only applies if the quote character immediately precedes the
  68. opening brace, and immediately follows the closing brace, with no whitespace.
  69. User callback functions are defined by passing a function object to the
  70. template processor. Function names appearing in the text are first checked
  71. against built-in function names, then against the method names in the function
  72. object. The function object forms a sandbox for execution of the template, so
  73. security-conscious users may wish to avoid including functions that allow
  74. arbitrary filesystem access or code execution.
  75. The callback function will receive its parameters as strings. If the
  76. result of the function depends only on the arguments, and certain things
  77. understood to be "static", such as the source code, then the callback function
  78. should return a string. If the result depends on other things, then the function
  79. should call cbt_value() to get a return value:
  80. return cbt_value( $text, $deps );
  81. where $deps is an array of string tokens, each one naming a dependency. As a
  82. shortcut, if there is only one dependency, $deps may be a string.
  83. ---------------------
  84. Tim Starling 2006