Manual:Parser functions/cs

Funkce analyzátoru, přidané v MediaWiki 1.7, jsou typem rozšíření, které se úzce integruje s analyzátorem. Fráze "funkce analyzátoru" by se neměla zaměňovat s, což je sbírka jednoduchých funkcí analyzátoru. (Viz .)

Popis
Zatímco se očekává, že rozšíření tagu vezme nezpracovaný text a vrátí HTML do prohlížeče, funkce analyzátoru může "interagovat" s ostatními prvky wiki na stránce. Například výstup funkce analyzátoru lze použít jako parametr šablony nebo při konstrukci odkazu.

Typická syntaxe funkce parseru je:

Další informace najdete v pro. Tato dokumentace uvádí:


 * Funkce zpětného volání by měla mít tvar:
 * Nebo s :
 * Nebo s :

První varianta volání předává všechny argumenty jako prostý text. The second passes all arguments as an array of s, except for the first, which is currently text, though this may change in the future. Ty představují nerozbalený wikitext. The  parameter can be used to expand these arguments as needed. To se běžně používá pro podmíněné zpracování, takže pomocí funkce analyzátoru typu if nebo switch se vyhodnotí pouze "skutečný" případ. Objekt frame může také vylézt po stromě dokumentu, aby získal informace o volajícím, a má funkce pro určení a správu hloubky volání, doby trvání a toho, zda je výsledek funkce analyzátoru nestálý.

Vytvoření funkce analyzátoru je o něco složitější než vytvoření nového tagu, protože název funkce musí být kouzelné slovo, klíčové slovo, které podporuje aliasy a lokalizaci.



Jednoduchý příklad
Below is an example of an extension that creates a parser function.

The registration goes into extension.json and the code into src/ExampleExtensionHooks.php respectively:

Another file, ExampleExtension.i18n.php, in your extension directory (Not in the src/ subdirectory) should contain:

With this extension enabled,



produces:


 * param1 is hello and param2 is hi and param3 is hey

Within LocalSettings.php
Magic words and their handling parser functions can be defined entirely in.

Longer functions
For longer functions, you may want to split the hook functions out to a _body.php or .hooks.php file and make them static functions of a class. Then you can load the class with and call the static functions in the hooks; e.g.:

Put this in your  file:
 * See: writing an event handler for other styles.

Then put this is in your  file:

Kešování
As with tag extensions, may be used to disable the cache for dynamic extensions.

This has a significant negative impact on performance, so only use when necessary.

Controlling the parsing of output
To have the wikitext returned by your parser function be fully parsed (including expansion of templates), set the  option to false when returning:

It seems the default value for  changed from false to true, at least in some situations, sometime around version 1.12.

Conversely, to have your parser function return HTML that remains unparsed, rather than returning wikitext, use this:

Naming
By default, MW adds a hash character (number sign, "#") to the name of each parser function. To suppress that addition (and obtain a parser function with no "#" prefix), include the SFH_NO_HASH constant in the optional flags argument to setFunctionHook, as described below.

When choosing a name without a hash prefix, note that transclusion of a page with a name starting with that function name followed by a colon is no longer possible. In particular, avoid function names equal to a namespace name. In the case that interwiki transclusion is enabled, also avoid function names equal to an interwiki prefix.

The setFunctionHook hook
For more details of the interface into the parser, see the documentation for setFunctionHook in includes/Parser.php. Here's a (possibly dated) copy of those comments:

function setFunctionHook( $id, $callback, $flags = 0 ) Parametry:


 * string $id - The magic word ID
 * mixed $callback - The callback function (and object) to use
 * integer $flags - Optional, set it to the SFH_NO_HASH constant to call the function without "#".

Return value: The old callback function for this name, if any

Create a function, e.g.,. The callback function should have the form:

The callback may either return the text result of the function, or an array with the text in element 0, and a number of flags in the other elements. The names of the flags are specified in the keys. Valid flags are:


 * forceRawInterwiki
 * Force interwiki transclusion to be done in raw mode, not rendered.


 * found
 * The text returned is valid, stop processing the template. This is on by default.


 * isChildObj
 * The text is a DOM node needing expansion in a child frame.


 * isHTML
 * The returned text is HTML, armour it against wikitext transformation. But see discussion


 * isLocalObj
 * The text is a DOM node needing expansion in the current frame.


 * noparse
 * Unsafe HTML tags should not be stripped, etc.


 * nowiki
 * Wiki markup in the return value should be escaped.


 * preprocessFlags
 * Use these flags when parsing the returned text. This only applies when noparse is.


 * text
 * The text returned from the function. If isChildObj or isLocalObj are specified, this should be a DOM node instead.


 * title
 * The Title object where the text came from.

Expensive parser functions
Some parser functions represent a significant use of a wiki's resources and should be marked as "expensive". The number of expensive parser functions on any given page is limited by the setting. What counts as expensive is left up to the function itself, but typically, anything that is likely to cause a delay that extends beyond simple processing of data should be considered. This includes things like database reads and writes, launching a shell script synchronously, or file manipulation. On the other hand, not all such functions should necessarily be tagged. Semantic MediaWiki, for example, only marks a percentage of its database reads as expensive. This is due to the fact that on certain data-intensive pages, it could easily overflow the normal expensive parser function limits. In cases like this, the potential for noticeably slower performance that doesn't get flagged as expensive is a trade-off to having the functionality that SMW offers.

To mark your parser function as expensive, from within the body of the function's code, use. The return value will be if the expensive function limit has been reached or exceeded.

Named parameters
Parser functions do not support named parameters the way templates and tag extensions do, but it is occasionally useful to fake it. Users are often accustomed to using vertical bars ( | ) to separate arguments, so it's nice to be able to do that in the parser function context, too. Here's a simple example of how to accomplish this:



Viz též

 * The ParserFunctions extension is a well-known collection of parser functions.
 * - an (incomplete) list of parser functions provided by core and extensions
 * The ParserFunctions extension is a well-known collection of parser functions.
 * - an (incomplete) list of parser functions provided by core and extensions
 * The ParserFunctions extension is a well-known collection of parser functions.
 * - an (incomplete) list of parser functions provided by core and extensions
 * The ParserFunctions extension is a well-known collection of parser functions.
 * - an (incomplete) list of parser functions provided by core and extensions
 * - an (incomplete) list of parser functions provided by core and extensions
 * The Parser Hooks PHP library, which provides an object orientated interface for declarative parser hooks