Content deleted Content added
full draft save |
Added the page to Category:Module documentation pages |
||
| (14 intermediate revisions by 12 users not shown) | |||
Line 1:
{{Module rating |release<!-- Values: pre-alpha • alpha • beta • release • protected -- If a rating not needed/relevant, delete this template call -->}}
<!-- Please place categories where indicated at the bottom of this page and interwikis at Wikidata (see [[Wikipedia:Wikidata]]) -->
{{High-risk|2,000,000+}}
{{TOC right}}
{{Module rating|protected}}
This was originally developed to optimize string concatenation as a helper method within [[Module:Asbox]], but has been generalized for all modules.
The interface for [[#Buffer object|Module:Buffer objects]] is similar to that of {{Luaref|HTML_library|mw.html}} objects in that you may build complex strings with independent child nodes. In most cases, you may use Buffer objects like a normal string, including using {{code|..}} operator. See also: [[#String, mw.ustring, and mw.text libraries]]
Additionally, there are several specialized forms and extended objects, described further in their respective sections:
*{{luaself|:stream|plain=y}}
*{{luaself|\-HTML|plain=y}}
Line 23 ⟶ 16:
*{{luaself|\-nil|plain=y}}
*[[#_G object|_G (callable)]]
Last but not least, this module has an ordered [[#require'Module:Buffer'.__pairs|__pairs]] which can be more thorough than {{luaref|ipairs||y}} and {{luaref|pairs||y}}. (Even reads nil keys!) The <span title='This is a bad Star Trek joke'>logical uniqueness</span> of this iterator may be reason enough to {{luaref|require|assimilate|y}} Module:Buffer.
==Usage==
{{anchor|module|initialize}}
===require'Module:Buffer'===
{{luaself|Buffer|\|require'Module:***'|subpage= |args=...|args2=_G, name, ...}}
Creates a new Module:Buffer object when the module returned by {{luaref|require||y}} is called as a function{{--}}i.e., there is no 'main'.
Because <span title='i.e. never accept arguments'>{{luaref|mw.html:done|public methods with useless parenthesis|y}}</span> are a [[pet peeve]] of this developer, this forwards arguments to {{luaself|:_}}; if that op is not desired, you may chain a Buffer object function directly to the module and the self-action will be redirected to a new Buffer object{{--}}i.e [[#Buffer:_inHTML|{{code|lang=lua|require'Module:Buffer':_inHTML'table'}}]] is equivalent to {{code|lang=lua|require'Module:Buffer'():_inHTML'table'}}.<ref group="note">For your convenience, the self operator {{code|:}} and {{code|.}} are interchangeable when used on the Module directly, though the self-op is required for nearly all other interactions with objects created by the Module.</ref>
The global variable {{luaref|_G}} is "magic" when passed as the first arg. Such enables the [[#Global functions|global functions]] and, if followed by a <code>name</code> string, will declare the new Buffer with that name in the global scope. If the argument following ''name'' is a table with no metatable, it and any other {{luaref|varargs||y}} are forwarded to {{luaself|:_all}}; otherwise, as long as the first vararg is not nil or false, this passes them to {{luaself|:_}}.<ref group="note">Passing arguments after ''name'' is primary used when {{luaself|:_in}} is indirectly called by {{luaself|:_all}} or {{luaself|pre=Element-|:_add}}. For example:
{{code|1=require'Module:Buffer'(_G,'arg'):_all({'arg',arg and {' was saved:' ,_in={_G, 't', ' awesome'}{{))}}, true):_(t and {t(), t..'r', t..'st'})|lang=lua}}
produces: {{code|arg was saved: awesome awesomer awesomest|lang=lua}}</ref> The _G passed may also gain a __call {{luaref|Metatables|metamethod|y}} (details at [[#G object|_G object]]).
{{anchor|recycling}}
As a final note, if you {{luaref|require|plain=y}} text from a module which returns a Buffer object, it may be more efficient to create a new Buffer via chaining {{luaself|Buffer|:_in|:_in|args=()}} after a require statement for the other module and use {{luaself|:_parent|args=()}} at the point where you would append the required text. (Best add {{code|lang=lua|1=--:_in == indirect require Module:Buffer}} so future editors won't hunt for {{code|lang=lua|function ...:_in}} at the other module)
===Basic functions===
{{anchor|Buffer}}
====Buffer object====
{{luaself|\|args=sep, i, j}}
Get a Buffer as a {{luaref|string||y}} via a function call on the Buffer ''object'' (as opposed to [[#require'Module:Buffer'|a call on the ''module'']]). This is basically shorthand for {{luaref|table.concat|args=Buffer, sep, i, j}}, or, with no args, {{luaref|tostring|args=Buffer}}. However, if this Buffer is in [[#raw|raw mode]]<ref group="note" name="raw" /> or contains at least one {{luaref|sequence|non-sequential|y}} index, this reconstructs the Buffer by creating a new table, coercing it contents to strings and appending them sequentially to the temporary "buffer" via <code>new-{{luaself|:_all|plain=yes|args=Buffer}}</code> (or a similar process).
Unconventionally, any {{luaref|string||y}}-type position passed as <code>i</code> or <code>j</code> are treated as ''relative to length''; that is, {{luaself|\|args='-', -1, '-3'}} is equivalent to {{luaself|\|args='-', -1, #Buffer - 3}} (which obviates the need to {{luaref|Local variable declarations|declare a local|y}} ''Buffer'' just to use the {{luaref|Length operator|length operator|y}}). Moreover, unlike table.concat, this automatically adjusts numerical<ref group="note">Later sections may describe values as being ''numerical'' or ''numeric''. Though perfect synonyms in normal usage, these adjectives are not interchangeable here. For the purposes of documenting Module:Buffer, ''numerical'' includes both actual number values and string values which {{luaref|tonumber|args=value}} does not return nil (and often involves Buffer-style length relativity); ''numeric'' describes values of number type only.</ref> positions to be within the range of the lowest and greatest indicies.
Note you may append a Buffer object without tostring coercion to an {{luaref|HTML library|mw.html|y}} object via {{luaref|mw.html:node}} (though not mw.html:wikitext because of type checking).
=====Buffer.last_concat=====
When strung without a ([[#valid|valid]]) <code>sep</code>, the result is cached at <code>Buffer.last_concat</code>. Until purged, future calls to return that Buffer as a string will return this index instead.<ref group="note">Using {{luaself|:_var|plain=y}} prevents future caching on all Buffers, though Buffers which already unmodified Buffers will continue to return their cached version</ref>
This should clear automatically whenever a Buffer object function changes the contents of a Buffer. You may manually purge the cache by setting this key to nil, as well as by passing nothing to {{luaself|:_cc|args=()}}.
====Buffer:_====
{{luaself|:_|args='string'|args2=value, pos, raw|args3=value, raw}}
Appends a value to the Buffer. In rough terms, {{code|lang=lua|Buffer:_'string1':_'string2'}} is the same as {{code|lang=lua|Buffer {{=}} Buffer..'string1'..'string2'}}. (It may help to imagine {{code|:_}} as a {{code|..}} that has stood up and is now casting a shadow.)
{{anchor|valid|invalid|no-op}}
Line 101 ⟶ 67:
* {{luaref|table||y}} without a __tostring metamethod and which {{code|table[1]|lang=lua}} is nil or false
A table with no __tostring will pass through {{luaref|table.concat}} before insertion. An {{luaref|error|plain=y}} may be thrown if the table would cause table.concat to error. (Use {{luaself|:_all}} instead for such tables.)
When passed {{code|pos}} of type {{luaref|number|plain=y}}, the argument is identical to ''pos'' for {{luaref|table.insert|args=table, pos, value}}. In fact, assuming a [[#valid|valid value]], {{luaself|:_|args='string', 1}} is exactly the same as {{luaref|table.insert|args=Buffer, 1, 'string'}}.
Just like with the position arguments of [[#Buffer|Buffer()]], any ''pos'' of type {{luaref|string|plain=y}} would be treated as relative to length.
{{anchor|raw}}
Set {{code|raw}} to true to force append a ''value'' without tostring coercion, including [[#no-op|invalid]] values.
====Buffer:_nil====
{{luaself|:_nil|args=pos, replacement|args2=replacement}}
Line 125 ⟶ 83:
If a non-boolean {{code|replacement}} is provided, then it will replace the value indexed at ''pos''. Passing a boolean as the second argument is a no-op.
When ''replacement'' is nil, the op is basically {{luaref|table.remove|args=Buffer, pos}}. As with the positional arguments of other Buffer methods, any numerical string ''pos'' is added to length, such that {{luaself|:_nil'0'}} removes the last item. Note the only type check on replacement is a direct comparison to both booleans (nil is implied). Any other type, including strings, sets the Buffer to [[#raw|raw mode]].
A ''pos'' that is omitted, nil, or false has the same effect as though <code>'0'</code> (or {{luaself|pre=#|\}}) were passed. Given only one non-numerical argument which evaluates true but {{luaref|tonumber||y}} would return it as nil, this treats it as though it were passed as the second. If passed a non-numerical ''pos'' with any other argument, including nil, this is effectively a no op (though may still purge the [[#Buffer.last_concat|cache]]).
====Buffer:_all====
{{luaself|:_all|args={ value, ... }|args2={ ..., value = pos, functionName = args, ... }, nanKeys}}
Takes a table {{code|value}}, iterates through all number keys {{luaref|table.sort|in order|plain=yes}}, appending each [[#valid|valid]] value to the end of the Buffer. In contrast to {{luaref|ipairs}}, this starts at the most negative key (down to {{luaref|math.huge|-inf|y}}) and ends at the most positive index, continuing through any nil keys and includes [[Double-precision floating-point format|non-integer number keys]].
A table ''value'' that has no metatable will have its contents iterated by this function before moving on to the next value. All other data types are processed by {{luaself|:_}}.
{{anchor|nanKeys}}
By default, this ignores non-number keys unless {{code|nanKeys}} evaluates true. If so, non-number keys are processed after number keys. Keep in mind such keys are iterated in {{luaref|next|no particular|y}} order, though an order may be imposed by wrapping each pair in a table indexed at a number key.
If given a <code>''value'' = ''pos''</code> pair, defined as a number or number string indexed at a non-number key, then they will be passed as the {{code|value}} and {{code|pos}} arguments for {{luaself|:_|plain=y}}. Thus,
:{{luaself|:_all|args=({1,2,3,'... done',[3.5]=variable and 4 or {four='1',zero=1{{))}},true)}}
produces the same result as:
if variable then
Buffer:_(4)
Line 163 ⟶ 110:
Buffer:_'... done'
--returns "1234... done" if variable evaluates true or "zero123four... done" if false|lang=lua}}
If a non-number key points to a value that cannot be coerced into a {{luaref|tonumber|coerced into a number|y}} then the pair may be treated as <code>''functionName'' = ''args''</code>, when ''functionName'' matches a Buffer object function and ''args'' is not boolean. If ''args'' is such that {{code|value[1]|lang=lua}} evaluates true, then this will pass the return of {{luaref|unpack|args=value, 1, table.maxn(value)}} to the named function; otherwise, the value is passed as is.<ref group="note">In other words, if ''args'' is a string or a table without [1] set, it will be passed as the only argument. Further note it is not possible to pass a <code>''functionName'' = ''args''</code> pair where ''args'' is numerical since such would be read as <code>''value'' = ''pos''</code>. Finally, passing a function type as ''args'' will throw an error message.</ref>
====Buffer:_in====
{{luaself|:_in|args=...|args2=_G, name, save, ...}}
Passes any arguments to [[#require'Module:Buffer'|Module:Buffer]] to create a new Buffer object, sets an external reference to the parent Buffer and returns the child.<ref group='note' name='in-dependents'>There is no 'getChild' method. If a child needed after returning to the parent, set it {{luaref|Local_variable_declarations|locally|y}} or use {{luaself|:_G}} prior to returning or it may become irretrievable. (No, {{u|Codehydro}} did not get lazy. Rather, this allows {{luaref|Garbage collection|garbage collection|y}} on children with no further purpose.)</ref>
This does <u>not</u> append the child to the parent. (See {{luaself|:_out|plain=y}})
Line 186 ⟶ 123:
====Buffer:_out====
{{luaself|:_out|args=sep|args2=ops, sep{{ndash}}list, { default{{ndash}}sep, ..., [#] = sep }|args3=0, sep}}
[[#Buffer object|Joins a Buffer]] with {{code|sep}} and appends result to its parent, which is returned. If no parent is found, this is a no-op and returns the same Buffer.
When given two or more arguments, this reads the first as {{code|ops}}{{--}}the number of :_out() operations to perform.<ref group="note">The first arg is not type checked but read as ''ops'' only when multiple args are present (or if it is the number 0); i.e., <code>Buffer:_out(2)</code> uses <code>2</code> as a separator. To append to the ''N''th ancestor with no separator, use <code>Buffer:_outs(''N'', nil)</code>.</ref> This applies the first ''sep'' in {{code|sep-list}} for the current Buffer, the second for its parent, the third for its grandparent, and so on.
If the last item is a {{luaref|table||y}}, then any ''nil'' in ''sep-list'' default to <code>''table''[1]</code>; any ''false'' mean "no-sep".<ref group="note">Empty strings would produce the same output as false, however, Lua string literals create objects that take up memory until garbage collected.</ref> The table may be the second arg (i.e. ''sep-list'' may be omitted). If it has other keys, then ''table[n]'' would apply instead of ''table[1]'', making these synonymous:
{{luaself|:_out|args=4, nil, nil, nil, ' and ', {', '} }} and {{luaself|:_out|args=4, {', ', [4] = ' and '} }}.
The number {{code|lang=lua|0}} is "magic" when passed as the first arg (even by itself), joining and appending to the same Buffer ''after'' it has been {{luaself|Buffer|:_cc|emptied|y}}. This is the only method by which a Buffer in [[#raw|raw mode]] may lose that status. Parent references are preserved.
====Buffer:_str====
{{luaself|:_str|args=sep|args2=ops, sep{{ndash}}list, { default{{ndash}}sep, ..., [#] = sep } }}
Line 221 ⟶ 147:
====Buffer:_cc====
{{luaself|:_cc|args=clear, copy, meta|args2=0, true}}
Nils all keys of the table referenced by {{code|clear}} and unsets its metatable. If ''clear'' evaluates false, this simply purges the cache at {{luaself|.last_concat}}.
If given a table to {{code|copy}}, this will duplicate all key-value pairs of ''copy'' into ''clear'', cloning any table value recursively via {{code|lang=lua|Buffer:_cc(0, value)}}. This returns the Buffer unless passed the number {{code|lang=lua|0}} as ''clear'', which causes this to create a new table and return that instead. Passing {{code|lang=lua|true}} as ''copy'' is equivalent to passing the Buffer itself. If ''copy'' is not a table, then it will be set as the first item in ''clear'' as long as it is not ''false''.
While this may resemble {{luaref|mw.clone}}, there are several differences, namely that this:
* Gives ''clear'' the same metatable as ''copy'' (or sets <code>meta</code>, if given) as opposed to a "clone" of the metatable.
* Conserves {{luaref|Length operator|Length|y}} attribute (though empty strings may replace some nil keys<ref group="note">For example, given {{code|lang=lua|{nil, 'string'} }} as ''copy'', {{code|lang=lua|Buffer:_cc(clear, copy)}} makes {{code|lang=lua|#clear}} equal <code>2</code>, whereas {{code|lang=lua|#mw.clone{nil, 'string'} }} equals <code>0</code> (as of March 2015). This replicates length by filling clear halfway to the length of copy (the minimum needed to 'trick' Lua) and then setting nil every key that would not trigger recalculation. As a result, keys that would resize ''clear'' when set nil are left as empty strings. Such should be fairly rare; given tables representing every possible way to position a single nil key for all lengths between 2 and 32 (inclusive), only 8.39 percent of such tables would have its nil copied as an empty string instead.Also note that tables returned from {{code|lang=lua|Buffer:_(0, copy)}} have length declared on creation instead, and thus won't have extra strings attached. The odds can be estimated using <math>y {{=}} 0.5 / \sqrt{x}</math>, where <math>y</math> is the upper limit that an arbitrary nil key from ''copy'' of length ranging from 1 to <math>x</math> is imaged as an empty string.</ref>)
* {{luaref|Rawset||y}}s values and iterates without invoking any __pairs {{luaref|Metatables|metamethod|y}}.
* Includes Buffer parent and [[#raw|raw]] attributes (stored externally)
Line 244 ⟶ 162:
====Buffer:_parent====
{{luaself|:_parent|args=sep|args2=ops, sep{{ndash}}list, { default{{ndash}}sep, ..., [#] = sep } }}
Resembling the reverse of {{luaself|:_out}}, this calls {{luaself|:_str}} on the Buffer's parent with the arguments given and appends the strung ancestor(s) to the current Buffer, which is returned.
Line 253 ⟶ 170:
====Buffer:getParent====
{{luaself|:getParent|args=value|args2=functionName, ...}}
Returns parent Buffer, or, if none exists, creates a new Buffer and returns it as the adopted parent. As with {{luaself|:_in}}, this does not automatically append the adoptive child to the new parent.
Pass a non-false <code>value</code> and this performs an op on the parent object.
If passed anything other than ''value'' (including nil), this requires that ''value'' names a function available to the parent object, which this calls and forwards the additional {{luaself|varargs|plain=yes}}.
Pass only a table ''value'' which has no metatable and this forwards ''value'' to the parent which calls {{luaself|:_all|args=value}}.
Given only a string starting with {{code|_}} and naming a parent function, this calls it on the parent without arguments. Any other [[#valid|valid]] singular argument [[#Buffer:|appends]] to the end of the parent Buffer.<ref group="note">In other words, {{luaself|:getParent|args='_nil'}} is shorthand for {{luaself|:getParent|args=():_nil()}}, however, {{luaself|:getParent|args='match'}} simply appends "match" to the parent. Note that you may still call {{luaself|Buffer|library|***:match|args=pattern}} on a parent via {{luaself|:getParent|args='match', pattern}}.</ref>
====Buffer:killParent====
{{luaself|:killParent|args=...}}
Line 285 ⟶ 194:
===Stream mode===
====Buffer:stream====
{{luaself|:stream|args=...}}
Switches a Buffer to [[#Stream-Buffer|stream mode]]. While streaming, the __call metamethod will append values to the end of the Buffer instead of the [[#Buffer object|usual op]].
Aside from that, there is only one other function: {{luaself|pre=Stream{{ndash}}|:each}}. Any args passed to Buffer:stream are forwarded to that function for a reason that should be evident when you finish reading this very short section.
No special action is needed to exit this mode. The normal call to string op is restored upon the use of any regular Buffer function or any operation which coerces the Buffer into a string (e.g. the <code>..</code> operator).
{{anchor|Stream-Buffer}}
====Stream-Buffer object====
{{luaself|pre=Stream-|\|args='string'|args2={concat{{ndash}}list}|args3=(var)}}{{anchor|streaming|calling a Buffer:stream}}
Stream-Buffer objects accept only one argument which they append if [[#valid|valid]]. That is, the op is a streamlined version of {{luaself|:_}} sans the ''pos'' and ''raw'' args.
This also exploits {{luaref|named arguments|the syntactic sugar of function calls|y}} to append a series of string literals (and tables) with nothing between them (or only {{luaref|Character class|ASCII space chars|y}} if desired).
For example, both A and B will produce identical strings:
'or even tab and line-break characters'<nowiki />'and continue to append individually'<nowiki />'for use with a joiner'
local B = require'Module:Buffer':_'A string of text may flow':_'with nothing between each string' :_ 'or perhaps only a space'
:_'or even tab and line-break characters':_'and continue to append individually':_'for use with a joiner'
Line 317 ⟶ 219:
true A string of text may flow with nothing between each string or perhaps only a space or even tab and line-break characters and continue to append individually for use with a joiner
|lang=lua}}
====Stream-Buffer:each====
{{luaself|pre=Stream-|:each|args=...}}
Appends an undetermined number of [[#valid|valid]] values to the Buffer object.<ref group="note">This is no different than calling the Stream-Buffer object directly with each item in the {{luaref|expression list}}; however, after noting how numbers and variables (too shy to [[skinny dip]] without parenthesis) could look rather odd swimming fully clothed in a stream of naked strings, this was made for those whose aesthetics prefer {{luaself|pre=Stream-|:each|args=('A',arg,'B',arg2)}} over {{code|lang=lua|Stream{{ndash}}Buffer'A'(arg)'B'(arg2)}}.</ref>
If the above line gives you [[Déjà vu]], that is because it is drawn from {{luaref|mw.html:wikitext|plain=y}}. However, unlike mw.html:wikitext, this does ''not'' stop at the first ''nil'' value.<ref group="note">If you want something like {{code|lang=lua|:wikitext('string1', varName, 'string2')}} such that ''varName'' is shorthand for an {{code|lang=lua|if}} statement that appends ''varName'' and 'string2' when the former is not nil, use {{code|lang=lua|:each('string1', {varName, 'string2'})}} instead.</ref>
==HTML library extension==
Upon the first call to {{luaself|:_inHTML}}, Module:Buffer clones the {{luaref|HTML library|mw.html object metatable|y}}, adding Module:Buffer's __eq and __concat metamethods along with a few additional functions.
Line 349 ⟶ 237:
====Buffer:_inHTML====
{{luaself|:_inHTML|args=tagName, args|args2={ args{{ndash}}list } }}
Accepts the same parameters as {{luaref|mw.html.create||y}} to create and return a [[#Buffer-HTML|modified mw.html object]]. As with {{luaself|:_in}}, this does ''not'' append the child object to the parent Buffer and instead sets a Buffer-style parent reference.
An exception to the above is when chaining this to an [[#Element-Buffer|''Element-''Buffer]] and such produces a ''selfClosing'' tag; when both conditions are met, this appends the tag and returns to the same Buffer.<ref group="note">That is, Element-Buffer{{code|lang=lua|:_inHTML'br'}} may be shorthand for {{code|lang=lua|:tag'br':done()()}} when planning to continue using Buffer object functions. This "auto-done and back" for selfClosing tags does not apply to non-element Buffers in order not to encourage the use of Buffer:_inHTML for simple tags as per [[#Tips and style recommendations]].</ref>
Unlike mw.html.create, if {{code|args}} has keys other than <code>args.parent</code> and <code>args.selfClosing</code>, it will pass for further processing through {{luaself|pre=Element-Buffer|:_add|plain=y}} (a cousin of {{luaself|:_all|plain=y}} that handles mw.html functions). Moreover, if passed a table where mw.html.create expects ''tagName'', this treats it as ''args'' instead.
Finally, this does not automatically set the <code>mw.html.parent</code> reference, making this an alternative to mw.html:tag
====Buffer:getHTML====
{{luaself|:getHTML|args=value|args2=functionName, ...}}
Line 373 ⟶ 259:
====Buffer:_html====
{{luaself|:_html|args = at, raw|args2 = raw}}
Line 380 ⟶ 265:
This (re-)appends the [[#lastHTML|last Buffer-HTML object]] to the current Buffer object. The <code>raw</code> and <code>pos</code> args are generally the same as those in {{luaself|:_}}.
When called with no arguments on an ''Element-''Buffer, this appends lastHTML without [[#raw|string coercion]]. Be warned however that if the Element-Buffer belongs to lastHTML or one of its tags, such will cause an [[infinite loop]], which can be avoided by passing an explicit nil to append lastHTML as a string.<ref group="note">{{luaself|\-HTML:_parent}} serves a similar role, but appends Buffer objects rather than HTML objects. Also Buffer-HTML:_parent only appends the string form of its ancestor object(s).</ref>
===HTML object functions===
Buffer-HTML objects may be used like any mw.html object. (In fact, merely replacing {{code|mw.html.create}} with {{code|require'Module:Buffer':_inHTML}} in an existing Module should produce the same output.)
{{anchor|wrapper}}
Most mw.html functions are unchanged, except {{luaref|mw.html:tag|:tag}}, {{luaref|mw.html:done|:done}}, and {{luaref|mw.html:allDone|:allDone}} are embedded in a wrapper function that checks whether they return a normal mw.html object. If so, switches the metatable to convert it to a Buffer-HTML object and sets a parent reference. <ref group="note">Buffer(-HTML) objects reference their parent differently from mw.html objects. Passing a normal mw.html object to Buffer:_inHTML as {{code|args.parent}} and then calling {{luaref|mw.html:done|:done}} the object created, followed by {{luaself|:getParent}} on the adopted parent, may return the "child." This is a feature rather than a bug.</ref>
As a side bonus, the {{code|..}} may be used on Buffer-mw.html objects directly (no {{luaref|tostring}} needed).
Line 394 ⟶ 277:
{{anchor|Buffer-HTML}}
====Buffer-HTML object====
{{luaself|\-HTML|args='string'|args2={ args{{ndash}}list } }}
Call this object as a function to return its {{code|lang=lua|.nodes}} index<ref group="note">{{--}}the internal table which holds elements appended via {{luaref|mw.html:wikitext||y}}, {{luaref|mw.html:tag||y}}, and {{luaref|mw.html:node||y}}</ref>, which this converts to an {{luaself|pre=Element-|\|plain=y}} object, granting it the same metatable as regular Module:Buffer objects (as well as several additional "tricks") and assigning the Buffer-HTML as its parent Buffer.<ref group="note">Passing arguments for {{luaself|pre=Element-|:_add}} via the ''args'' parameter of {{luaself|:_inHTML}} and {{luaself|\-HTML:tag}} during the creation of a new Buffer-HTML object is the only way to use most Buffer object functions on the new HTML object without converting its <code>.nodes</code> into an Element-Buffer.</ref>
This takes one argument which is forwarded to its Element-Buffer. Tables pass to the specialized HTML builder {{luaself|pre=Element-|:_add}}. All other [[#valid]] values are appended to its Element-Buffer via {{luaself|:_}}.
Line 404 ⟶ 286:
|{{TOC tab|{{TOC tab|{{TOC tab|{{TOC tab|{{TOC tab||Buffer-HTML:_parent|depth=2}}|Buffer-HTML:_str|depth=2}}|Buffer-HTML:_out|depth=2}}|Buffer-HTML:killParent|depth=2}}|Buffer-HTML:getParent|depth=2}}
|}{{anchor|HTML version}}
You cannot chain call regular Buffer functions on a Buffer-HTML object; however, since mw.html functions cannot read Buffer-style parent references, modified versions of methods that return [[#Buffer:_inHTML|the parent Buffer]] are available to Buffer-HTML without having to call into the Element-Buffer. For convenience, {{luaref|mw.html:allDone}} is called automatically prior to the op, though after the <code>lastHTML</code> reference has been set for {{luaself|:getHTML}}.<ref group="note">That is, Buffer:getHTML may be used to return to the child node, though the trade off is that you may still need to call mw.html:allDone before using these methods in order to append the full HTML tree via [[#Buffer:_html|Buffer:_html]].</ref>
*{{replace|'''[[#Buffer:${{!}}:$]]'''|$|getParent}}
*{{replace|'''[[#Buffer:${{!}}:$]]'''|$|killParent}}
Line 413 ⟶ 293:
*{{replace|'''[[#Buffer:${{!}}:$]]'''|$|_str}} {{ref label|html-0-str|0}}{{ref label|html-ops-str|$}}
*{{replace|'''[[#Buffer:${{!}}:$]]'''|$|_parent}} {{ref label|html-parent|^}}
<div style='font-size:
{{note label|html-0-out|||{{note label|html-0-str|0|| if passed {{code|lang=lua|0}} as the first argument, these do not redirect the self-action via <code>:allDone()</code>, however, these always return a Buffer-HTML object (think <code>{{luaself|pre=Element-|:done|args=(0)|plain=y}}</code>). {{note label|html-0-out-perm|||For :_out only, the "magic" number zero ''permanently'' consolidates <code>Buffer-HTML.nodes</code> (whether or not converted)}} just like <code>:_out(0)</code> on a normal Buffer except it would not unset raw mode on an Element-Buffer.}}}}
Line 422 ⟶ 301:
{{note label|html-parent|^|| This takes arguments for {{luaself|:_str}} and calls it on the [[#Buffer:_inHTML|parent Buffer of the HTML tree]], returning and appending the result to the same Buffer-HTML object. In other words, the "auto-allDone" doesn't really apply here, or at least not in the same sense as with the other functions. (As a reminder, Buffer:_inHTML does not append to the parent Buffer those Buffer-HTML objects which it returns.)}}
</div>
In addition to the above, [[#gfuncs|global functions]] may be available to Buffer-HTML if enabled; these functions are the same for all Module:Buffer objects{{--}}i.e. the self action is never redirected.
Line 429 ⟶ 307:
{{anchor|Element-Buffer}}
====Element-Buffer object====
{{luaself|pre=Element-|\|args=sep, i , j}}
Sharing the same metatable as with regular Buffer objects, Element-Buffers concatenate the same way when [[#Buffer object|called]] to produce a string analogous to the [[JavaScript]] DOM [http://www.w3schools.com/jsref/prop_html_innerhtml.asp "innerHTML"] property. In other words, when strung, it is generally the contents of the Buffer-HTML object without the "outerHTML" or tag.
There are exceptions to this "innerHTML" behavior. For instance, as appended to another object via {{luaref|mw.html:node}}, an Element-Buffer and its Buffer-HTML are interchangeable (though appending the former via {{luaself|:_}} only includes the inner result).
Also, using the concatenation operator {{code|lang=lua|..}} on an Element-Buffer includes its tag in a manner depending on if it is selfClosing:
*For most tags, the conjoined string is placed inside the tag, e.g. {{code|lang=lua|Buffer:_inHTML'p' 'inner text' .. 1}} returns {{code|lang=lua|'<p>inner text1</p>'}}.
*For selfClosers, the {{code|lang=lua|..}} op redirects to its Buffer-HTML, e.g. insert [[#Element-Buffer:_add|{{code|lang=lua|1=:_add{selfClosing=true} }}]] in the above example before {{code|lang=lua|.. 1}} to produce {{code|lang=lua|'<p />1'}}.
:{{see|#Modified .. operator}}
You may use most Buffer object functions normally, however if there is a [[#HTML version|Buffer-HTML version]], it instead behaves as though chained on the [[#Buffer-HTML|outer HTML object]].<ref group="note">While Buffer-HTML objects may use [[#global functions]], there is no separate Buffer-HTML version. In other words, the self-action of a global function on an Element-Buffer is <u>not</u> redirected.</ref> You may also chain any mw.html object function. Unless otherwise indicated, such returns a [[#wrapper|wrapper]] method that merely redirects the self-action to the outside Buffer-HTML.<ref group="note">{{luaref|mw.html:allDone}} is doubly wrapped for Element-Buffers, with the other wrapper setting a Buffer parent reference as described at {{luaself|:_inHTML}}. Furthermore, {{luaself|pre=Element-|:tag}} and {{luaself|pre=Element-|:done}} do not call their mw.html namesakes at all, as detailed in their respective sections.</ref>
As a final note, Element-Buffers are in permanent [[#raw|raw mode]] since it is expected that some mw.html method (e.g. :tag and :node) may or will append non-string elements.
====Element-Buffer:done====
{{luaself|pre=Element-|\|args=ops}}
When passed nothing, this should behave just like {{luaref|mw.html:done}} as called the "outer" HTML object{{--}}returning <code>Buffer-HTML.parent</code>, if available, or Buffer-HTML if not.
However, this has been re-designed to accept {{code|ops}}, the number of :done() operations to perform. Thus, {{code|Element{{ndash}}Buffer:done(4)|lang=lua}} is equivalent to {{code|Buffer{{ndash}}HTML:done():done():done():done()|lang=lua}}.
Pass {{code|lang=lua|0}} (zero) as ''dones'' to return to the Element-Buffer's direct HTML container.
Line 470 ⟶ 334:
====Element-Buffer:tag====
{{luaself|pre=Element-|:tag|args=tagName, args|args2={ args{{ndash}}list } }}
This uses the same helper method as {{luaself|:_inHTML|plain=y}} to handle arguments and produce new Buffer-HTML objects, selectively passing ''args'' to {{luaself|:_add|plain=y}} when it contains keys not used by {{luaref|mw.html.create||y}}.
As may be expected, this differs from Buffer:_inHTML in that this actually appends the tag and will set a mw.html-style parent reference. This also lacks the other function's "auto-done" feature for selfClosing tags.
As with the other Element-Buffer remake of an mw.html method, the features described here do not apply to the version used by Buffer-HTML objects.
====Element-Buffer:_add====
{{luaself|pre=Element-|:_add|args=args|args2={ wikitext{{ndash}}list, { args{{ndash}}list }, ..., arg {{=}} value, functionName {{=}} args } }}
Takes a table as its only argument. This then thoroughly iterates all number keys from lowest<sup>[[#endnote_skip1|†]]</sup> to highest using [[#MBpairs|this module's custom __pairs]] method. Most values append as wikitext if [[#valid|valid]]. If a table is indexed at a number key, this [[Recursion (computer science)|recursively]] iterates the table before moving on to the next key.
After processing all number key-value pairs, this then iterates the other (non-number) keys. For those naming a [[#Basic functions|core Buffer object function]], this selectively unpacks {{code|args}} in a manner described at {{luaself|:_all}} when that function is passed the ''nanKey'' parameter (excepting that this does not read numbers as ''pos'', i.e. treats them the same way as strings).
This also accepts keys naming [[#HTML object functions|HTML]] and [[#Global functions|global functions]] as well as mw.html arguments. Thus, {{code|lang=lua|Element{{ndash}}Buffer:_add{ tag {{=}} 'br', 'text'} }} appends a BR tag ''after'' the text and {{code|lang=lua|Element{{ndash}}Buffer:_add{ {tag {{=}} 'br' }, 'text'} }} appends the BR before the text. Note however that how this handles ''args'' for such keys depends on the particular function or argument named:
======args.''argName''======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ arg = value } }}
The effect of passing ''args'' with keys such as <code>args.selfClosing</code> and <code>args.parent</code> is the same as though ''args'' were passed to {{luaref|mw.html.create}}. This also takes one additional ''arg'', i.e. <code>args.tagName</code>, which value replaces the original ''tagName'' of the HTML object (or, if false, removes the tag).
Note that these are the only keys for which a boolean ''arg'' would result in an op. (For Buffer object functions that do not no-op when passed only a boolean, place the boolean in an ''args'' table for unpacking.)
======args.''cssName''======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ cssName = cssValue } }}
A non-number ''key'' and ''value'' pair may default as the <code>cssName</code> and <code>cssValue</code> parameters for {{luaref|mw.html:css}} when the key matches none of the three [[#args.argsName|argName]] keys nor the name of any available function for Buffer and mw.html objects.
This sends non-boolean ''cssValue'' though {{luaref|tostring||y}} prior to forwarding it to mw.html:css. Because this is the default, any typoed key goes to mw.html:css as ''cssName''. Names of functions not yet [[#loadable|loaded]] also end up there.
For convenience, any <code>_</code> character in the key string is automatically substituted with the <code>-</code> character; thus {{code|lang=lua|1=border_bottom_style =}} is equivalent to {{code|lang=lua|1=['border-bottom-style'] =}}.
The form {{code|lang=lua|1=Element-Buffer:_add{ css = { cssName = cssValue } } }} also works (or to clear a previously set value; see example at [[#args.htmlFunction|args.htmlFunction]] for more details).
{{anchor|args.tag}}
======args.tag<sup>[[#endnote_skip1|†]]</sup>======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ tag = tagName } }}
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ tag = { tagName, args{{ndash}}list } } }}
Set the key <code>args.tag</code> to a string and this calls {{luaref|mw.html.create||y}} with it as the ''tagName'' argument. This then raw inserts the returned mw.html object ("tag"), emulating the effect of {{luaref|mw.html:tag||y}} minus parent references, which are unnecessary.
Pair the ''args.tag'' key with a table value and this calls mw.html.create with {{code|lang=lua|table[1]}} as ''tagName'' (or nil if [[#invalid]]), appending it as described above for string values, but also pointing <code>tag.parent</code> to the [[#Buffer-HTML|Element-Buffer's parent]] as well as temporarily setting the tag as the parent Buffer of <code>tag.nodes</code>. This then treats tag.nodes as a ''[[pseudo]]-''Element-Buffer, [[Recursion (computer science)|recursing]] tag.nodes as "self" and the table as ''args'', though only iterating keys not equal to {{code|lang=lua|1}} (or less).[[#endnote_skip1-tag|<sup>[*]</sup>]]
Note this appends normal mw.html objects. That said, most Buffer functions named in ''args-list'' should still work as though the tag and <code>tag.nodes</code> were Buffer objects.<ref group="note">However, some Buffer methods may not work properly after appending objects via mw.html functions to the
Upon completing a recursive iteration for args.tag, this checks if the tag is selfClosing, in which case, this
{{anchor|args.done}}
======args.done<sup>[[#endnote_skip1|†]]</sup>======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ done = wikitext } }}
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ done = { ops, args{{ndash}}list } } }}
Similar to args.tag, this treats the first index of the table as the ''ops'' argument of {{luaself|pre=Element-|:done}}. After calling that function, this then iterates all subsequent keys in a recursive call on the Element-Buffer of the Buffer-HTML object returned.
======args.allDone======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ allDone = wikitext } }}
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ allDone = { args{{ndash}}list } } }}
Similar to the previous two, except that the first index is not used as an argument; thus, the entire table is iterated.
{{anchor|args.globalFunction}}
======args.''globalFunction''<sup>[[#endnote_skip2|‡]]</sup>======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ globalFunction = name } }}
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ _B = { var, args{{ndash}}list } } }}
If the [[#gfuncs|global functions]] have been loaded and a key matches one, this calls the function with the first two arguments {{luaref|unpack||y}}ed from the paired ''args-list'' table. This then recursively iterates the list, excluding keys less than or equal to {{code|lang=lua|2}}, with whatever object is returned as ''self''. However, if the returned object has a metatable and <code>object.nodes</code> exists, the ''self'' will be object.nodes instead.
Because {{luaself|:_B}} takes only one argument, args._B only unpacks the first index and starts the iteration after that key.
If neither of the first two keys evaluate true, this assumes the paired value is a string for use as the ''name'' argument for the function matching its key.<ref group="note">A caveat of this unconventional type checking is that pairing an args.globalFunction with a number value will throw an error (which shouldn't be a problem since numbers make poor names for global variables).</ref> In that case, the current call stack's ''self'' (an Element-Buffer or [[#args.tag|tag.nodes]] if this was called indirectly) is ''self'' for the global function.
======args.''htmlFunction''======
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ htmlFunction = object } }}
{{code|lang=lua|1=Element{{ndash}}Buffer:_add{ htmlFunction = { arg-list, name = value } } }}
If args.''key'' matches an {{luaref|HTML library|mw.html object function|y}} that does not have its own args section, this checks if the associated ''object'' is table. If not a table, or if <code>object.nodes</code> evaluates true, this calls the mw.html function with the object as the only argument.
For table objects without an object.nodes, this iterates the table (non-recursively), repeatedly calling the named mw.html function with one or two arguments depending on key's type in each loop. Non-number key-value pairs are both passed as arguments. For numeric indices, only the value is passed. Boolean values are a no-op.
Unlike with most implementions of [[#MBpairs|Module:Buffer's __pairs]], this first loops through ''non-''number keys, followed by number keys (still ordered from lowest to highest). Thus, something like {{code|lang=lua|1=Element{{ndash}}Buffer:_add{ attr = { 'width', width = 20 } } }} is equivalent to {{code|lang=lua|Element{{ndash}}Buffer:attr( 'width', 20 ):attr( 'width' )()}}, setting then unsetting the width attribute and returning the Element-Buffer for a net no-op (though the practical purpose of such is a mystery for this developer).
For <code>args.css</code> only, this auto-replaces underscores with hypens for string keys{{--}}i.e., you may save four keystrokes/pair by typing <code>css_property =</code> instead of <code>["css-property"] =</code>. This does not apply to strings indexed at number keys.
<div style='font-size:
----
{{note label|skip1|†|| Unlike with tables passed directly, [[Recursion (computer science)|recursive]] iterations for functions marked with <sup>†</sup> start at the smallest number greater than {{code|lang=lua|1}} instead of negative infinity.}}
{{note label|skip2|‡|| The iteration may start after {{code|lang=lua|2}} for some global functions.}}
</div>
{{anchor|loadable}}
Line 613 ⟶ 436:
The methods here are loaded on demand or depend on subroutines which need initialization.
These methods can greatly simplify the structure of the modules which employ them by doing, in a fluent manner, many tasks which may otherwise force an awkward interruption in Buffer call chains.
{{anchor|gfuncs}}
===Global functions===
Methods such as {{luaref|mw.html:done}} and {{luaself|:getParent}} traverse a node tree in only one direction. While fine for returning to an ancestor, they do not provide navigation to a non-ancestor (often necessary for templates with co-dependent parameters). Yet, repeated breaks in call chains to set local variables for several nodes of the same branch can look choppy if not confusing for nodes many generations removed from its declaration statement.<ref group="note">i.e., does ''x'', in the following, reference the TD or some other node hidden within an [[ellipsis]]?:
{{code|lang=lua|local x {{=}} mw.html.create():tag ... :tag'td' ... :tag(arg and 'div' or 'p'):wikitext( ... ):tag'br':done():done() }}</ref>
Templates with several conditionally-appended nodes with similar, but not identical, parts may present another conundrum for coders who must decide between having awkward call chain interruptions to store potentially repeated components as local variables or constructing a somewhat redundant module that is more susceptible to maintenance errors by future editors who may patch one code segment but miss the sibling buried within a convoluted nesting of {{luaref|Logical operators|logical operators|y}}.
This module's global functions and added [[syntactic sugar]] for the [[#G object|_G object]] were formulated to simplify such node trees with multi-conditional or repeating structures by providing concise in-chain variable declaration. The extension is enabled by passing your global table to the module{{--}}either in the initial call to [[#initialize|require'Module:Buffer']] (more instructions in that section) or to {{luaself|:_in}} which forwards arguments to Module:Buffer.<ref group="note">Global function are not enabled by default for various reasons:
* Most templates are one-dimensional (i.e. contain few if any nested conditional statements) and thus would not benefit from these methods.
* Loading them to the Module:Buffer meta index means more items that must be sifted through each time a specific function has to be retrieved.
Line 643 ⟶ 451:
* Excess use may clutter the global scope enough to slow access to basic Lua functions (e.g. {{luaref|type}} or {{luaref|pairs}}) even after Buffer methods are no longer used.
It should be mentioned however that variable retrieval even even in a relatively cluttered global scope is fairly trivial. In fact, early versions of Module:Buffer used globals extensively (and actually had no locals declared before the final return, or rather the entire module was just one long return statement). In contrast, the current version nests many {{code|lang=lua|do ... end}} blocks to limit scope size. Yet, {{luaself|:_}}, a core function which has changed little, is only a modest 10 percent faster than itself in the last unscoped version (not published); then again, perhaps the benefit of scope dieting has been masked by much greater total number of variables required by new features?</ref>
====Buffer:_G====
{{luaself|:_G|args=name, save}}
{{
Pass <code>name</code> and <code>save</code> to assign the object passed as ''save'' to a global variable via {{luaref|rawset|args=_G, name, save}}.<ref group="note">Actually, the first argument to rawset is a local variable <code>[[#new_G|new_G]]</code> which generally equals _G but not always, to be detailed in a later section.</ref>
Pass only ''name'' and this substitutes ''self'' for ''save'' to assign the Buffer object to <code>_G[name]</code> instead. Give an explicit nil as ''save'' to unset a global. This returns the Buffer object as well as any argument given after ''name''.
This is a no-op when ''name'' is nil or a boolean, or, when ''save'' (eventually) evaluates true and {{luaref|rawequal|args=save, rawget(new_G, name)}} also returns true.
{{anchor|metaglobal}}
If the named global already exists, this "backs up" the old value by moving it to the meta __index of the global table, setting a new metatable if none exists.<ref group="note">If the meta global has an __index which is a function, the back-up op aborts without throwing an error.</ref> Retrieving the old value requires unsetting the new one via {{luaself|:_R}} (more details in that section). If overwritten a third time, the first value is discarded and the second takes its place in the back up.
If a metaglobal variable exists but the global is nil, this sets the global without unsetting the metaglobal (i.e. does not back up a nil global). An exception is when this is given an explicit nil as ''save'' and only the metaglobal exists; thus, passing nil twice for the same ''name'', unsets the key in both the global table and its metaindex.
====Buffer:_R====
{{luaself|:_R|args=name, save|args2='new_G', var, metaindex}}
This {{luaref|rawset||y}} with the global table as the first argument and <code>name</code> and <code>save</code> as the second and third, respectively, returning the Buffer object for call chaining.<ref group="example">The following demonstrates how, by combining Buffer:_R and Buffer:_G, the global variable ''v'' can be declared, backed-up and replaced, replaced without back-up, restored from back-up, and removed completely:
{{#tag:syntaxhighlight|require'Module:Buffer'
(_G,'v') -- call module with global functions enabled and declare new buffer as v
:_'A' -- append 'A' to the returned buffer
Line 688 ⟶ 481:
:_G('v', nil)", " -- remove back-up and join the buffer with a separator
..' and '..tostring(v)-- returns 'A, 1, 2, A12 and nil'|lang=lua}}
{{anchor|new_G}}
{{see|#new_G object}}
Note that Buffer methods use a local variable <code>new_G</code> as a proxy for the global table _G; though not a global index, the string {{code|lang=lua|'new_G'}} is a "magic word" that changes the destination for future ''save'' for this and Buffer:_G.
Pass a table as <code>var</code> (same place as ''save'') to set as the ''new'' new_G. Any table such that {{code|lang=lua|1=var._G == _G}} is treated as a (former) new_G object. This {{luaref|getmetatable|gets the metatable|y}} of former proxies and {{luaref|setmetatable|sets a new table|y}} with the {{luaself|_G object|plain=y}} __call method on non-new_G tables. Then, this, if third parameter <code>metaindex</code> equals:
* nil {{--}} backs up the current proxy as the metaindex of the next (though this no-ops if ''var'' equals new_G to avoid cyclical indexing).
* false {{--}} leaves the metaindex intact (replacing the current proxy without back-up)
Line 705 ⟶ 493:
* any other value {{--}} sets that value as the metaindex of the next proxy. (Note new_G._G is not set until it is returned by {{luaself|:_2}})
To omit or to pass nil/false as ''var'' has the same effect as {{luaself|:_R|args='new_G', {} }}. Pass true instead and this treats it as though passed as ''metaindex'', creating a new proxy without backing up the incumbent.
====Buffer:_2====
{{luaself|:_2|args=name, save|args2='new_G', ...}}
Line 716 ⟶ 502:
In other words, {{luaself|:_2|args=name, save}} is roughly equivalent to {{code|lang=lua|1=_G[name] = _G[name] or save or save==nil and Buffer}}.
The string {{code|lang=lua|'new_G'}} will return the Module:Buffer local variable <code>[[#new_G|new_G]]</code>, used as a proxy for the global variable _G. Given more than one argument, this forwards arguments to {{luaself|:_R}} to assign another proxy global before returning the (newly-deposed) proxy. This then sets <code>new_G._G</code> to the original _G object for call chaining. (See § chain call in [[#G object|_G object]]).
====Buffer:_B====
Line 726 ⟶ 509:
Takes only one argument and returns that argument.
Assuming the only ''X'' declared is {{luaref|_G|_G.X}} and new_G equals _G, then {{luaself|:_B|args=(X)}} and {{luaself|:_2|args='X'}} are equivalent.<ref group=note>Dubbing this a "global function" is bit of a misnomer since this never retrieves anything from the global table. While designed for in-chain navigation to Buffer objects that were [[#Buffer:_G|self-declared as globals]], this returns any local reference or literal passed as well (allowing {{luaself|pre=Element-|:_add}} to execute Buffer methods on non-Buffer objects <code>[[#args.globalFunction|args._B]]</code>).</ref>
When passed a variable that does not exist, this returns the Buffer nil object:
Line 736 ⟶ 516:
{{anchor|Buffer-nil}}
=====Buffer-nil object=====
{{luaself|\-nil()}}
{{luaself|\-nil:anyName|args=():_B( var )}}
The Buffer-nil object is unique. Calling this as a function returns nothing (in contrast, calling an empty Buffer object returns an empty string). This does however have the Module:Buffer __concat metamethod, which treats this the same way as any [[#invalid|invalid]] object (i.e. ignores it).
Appending this via {{luaref|mw.html:node}} or {{luaself|:_}} has the same effect as appending nil. Passing this to {{luaref|tostring||y}} returns nil instead of the string 'nil'.
The only real Buffer method in its meta __index is {{luaself|:_B}}, however, any non-numerical key string retrieves a function that only returns the Buffer nil object for call chaining. In a sense, you can think of {{code|lang=lua|Buffer:_B(var):...}} as an {{code|lang=lua|1=if var~=nil then var:...}} block around the following chain that ends in the next :_B().
If {{luaref|mw.clone|cloned|y}}, the clone will be a normal Buffer object.
Line 753 ⟶ 530:
{{anchor|_G object}}<!--anchor below excludes the _ -->
====_G object====
The first _G variable [[#initialize|passed to this module]] is given a __call metamethod that self-{{luaref|rawset||y}}s and returns in a manner that depends on whether it was called directly or from a chain.<ref group="example">Saving a new_G object globally via a chain call can prevent conflict. The follow example has a hypothetical "Module:X" that may overwrite globals declared by your module or unwittingly discard your new_G when it passes _G to Module:Buffer (passing _G to this module resets new_G to the global table even when the global functions are already enabled):
{{#tag:syntaxhighlight|
return require'Module:Buffer'(_G)--Return before require to show intent to return a Buffer object; chain cannot be broken
:_R(frame.args.title and --store values outside global scope if invoked with title parameter
Line 776 ⟶ 548:
... )
:_R('new_G', my_G) --set my_G as new_G again and have the new_G from Module:X as its metaindex
:_(frame.args.detail and
my_G.info
:_(frame.args.detail)--append Buffer object from Module:X's new_G.info if args.details and it exists; append detail param to result
Line 791 ⟶ 563:
)
|lang=lua}}
=====direct call=====
<code>_G( k, v )</code>
<code>_G'string'</code>
When called, the _G object self-sets any string passed as <code>k</code> with whatever is passed as <code>v</code>. This returns ''v'', or nil if omitted (unlike with rawset, an explicit nil is not necessary to unset a variable with direct calls).
Note that ''k'' must be a string to declare or unset a global in this op. Tables passed as the first argument are treated as though this were executed via a call chain (discussed shortly). Passing ''k'' which is not one of those two types will throw an error.
=====chain call=====
<code>chained-object:_G( k, v )</code>
<code>chained-object:_G'string'</code>
{{
When used in a call chain, this rawsets the ''k''ey-''v''alue pair in the chained object and returns that object. The _G object may chain itself when returning _G is desired for another op instead of ''v''.
In contrast to the direct op, the in-chain op will index non-string ''k'' values. Moreover, this only unsets object[k] when passed an explicitly nil ''v''.
If ''v'' is omitted in-chain, this uses the chained object as the missing argument; thus, (chained) <code>object:_G'string'</code> has identical effect and return to <code>_G('string', object)</code>.
The same __call method is given to [[#new_G|new_G]] objects created by Buffer:_R, however the direct call only works if its metaindex is the _G object. Any table such that <code>table._G</code> points to the _G object may chain save to itself regardless of metaindex.
Though the behavior of the chain op when ''v'' is omitted may be a [[Dead ringer (idiom)|dead ringer]] to that of [[#Buffer:_G|Buffer:_G]] when ''save'' is omitted and [[#new_G|new_G]] is the chained object, mind that the Buffer object function sets keys in new_G variable rather than the chained (Buffer) object; in other words, this is unaffected by Buffer:_R reassigning new_G to another table. Also, this does not have the back up behavior of Buffer:_G.
{{anchor|Buffer-variable}}
Line 835 ⟶ 595:
====Buffer:_var====
{{luaself|:_var|args=var, change|args2={ ... }|args3=()}}
Raw appends a Buffer-variable object, which may appear as a different value each time the object (or its container) is converted to a string.<ref group="example">The following contrived example demonstrates most features of {{luaself|:_var|plain=y}}:
{{#tag:syntaxhighlight|local H, sep = require'Module:Buffer':_inHTML('div',{'Heading ',_var={nil,'odd','even'},color='blue',['text-decoration']='underline'})
:_out():_html(true):_html(true):_html(true)
sep = H:_in'This is ':_var():_' - ':_var'A':_var(3,-1):_'\n'
Line 852 ⟶ 609:
<div style="color:blue;text-decoration:underline">Heading even</div> This is even - D0
math: 0 + 5 = 5 ; 5 - 1 = 4 --]]|lang=lua}}
Initialize a Buffer-variable object by passing as <code>var</code> a:
* number - which, when strung the first time, appears as that number and reappears as <code>var + change</code> the next time it is strung.
* string - that transforms into the next [[ASCII]] character via {{luaref|string.char||args=var:byte() + change}}.
* table - to return the first (non-nil) item, then the second, and so on as determined by {{luaref|next|args=table}}, looping back to the first item after reaching the last. (Note the ''change'' argument does not apply to table-based Buffer-variables.)
* custom function - to be set as the _build and __tostring method of a variable-object, though instructions for coding such functions are beyond the scope of this manual.
Re-append the same variable object by passing {{code|lang=lua|true}} as the only argument. For non-table-based variables, you may specify ''change'' to append a sister object which transforms the value at the rate specified. Changes are cumulative. Thus, if the original is re-strung after a sister, its value will differ from that of its last appearance by the sum of the original and sister rates and vice versa.
Apply a ''change'' without appending a new variable object to the Buffer by passing {{code|lang=lua|false}}. The shift is effective immediately and may affect previously appended variable objects not yet [[#Buffer:_out|finalized]]. Pass only false (i.e., omit ''change'') to produce the same effect as stringing the original once. Note that the false-change is the only ''change'' table-based Buffer variables will honor.<ref group="note">False cycles tables based on {{luaref|Length operator|#|y}} instead of {{luaref|next}}, which may diverge or error if the table contains nil items.</ref>
Pass nothing to append a version which simply repeats the result of the last stringing. While generally identical in effect to the object generated by <code>:_var(true, 0)</code>, the Buffer-variable will return nothing if strung before any of its sisters.
If passed an explicit nil as the first argument, this is no-op. If passed a boolean before any Buffer-variable has been initialized, this is also a no-op. Note that any op disables future caching at {{luaself|.last_concat|plain=y}} for all Buffer objects in your module (and in any module which may require it).
{{anchor|library}}
Line 883 ⟶ 629:
====Basic usage====
{{code|lang=lua|Buffer:functionName( ... )}}
You may directly chain any function from the following libraries on Buffer objects:
* {{luaref|String library|string|y}}
* {{luaref|Text library|mw.text|y}}
* {{luaref|Ustring library|mw.ustring|y
Functions from these libraries added to the Module:Buffer metatable on-demand and placed within a wrapper method that strings the Buffer object for the first argument and then forwards the remaining arguments.
Thus, the following are equivalent: {{code|lang=lua|Buffer:nowiki( ... )}} and {{luaref|mw.text.nowiki|args=tostring(Buffer), ...}}
If a name exists in both the string and mw.ustring libraries, the string version takes precedence. You may [[prefix]] the letter ''u'' on any mw.ustring function{{--}}e.g. Buffer:ulen returns the number of unicode characters and Buffer:len returns the number of bytes.
Buffer:gsub and Buffer:ugsub have a slightly different wrapper which substitutes the <code>repl</code> argument of {{luaref|string.gsub||y}} and {{luaref|mw.ustring.gsub||y}} when it evaluates false or is omitted with an empty string (otherwise the originals would throw an error). This saves a few keystrokes when removing characters via {{code|lang=lua|Buffer:gsub'[pattern]'}} as opposed to {{code|lang=lua|Buffer:gsub( '[pattern]', '' )}}. All other arguments are handled the same as with the other on-demand methods.
Library functions which take a non-string as the first argument are not supported.
====Empty Buffer interface====
{{luaself|:_in|args=():functionName( ... )}}
To obtain the first return value as a Buffer object (as opposed to whatever type the original normally returns), simply chain the imported method immediately after creating the new Buffer via [[#Buffer:_in|Buffer:_in]]. Only empty Buffer objects which have a parent object will append the result of their parent in this manner.
This syntactic sugar allows two things:
Line 923 ⟶ 657:
: vs. the following which has the same order of operations albeit harder to see: {{code|lang=lua|1=mw.text.encode( mw.ustring.toNFD( Buffer:uformat( ... ) ), '[<>#]' ):match'^(.-)==='}}
=====Special case: Element-Buffer=====
{{code|lang=lua|empty{{ndash}}Element{{ndash}}Buffer:functionName( ... )}}
{{code|lang=lua|Element{{ndash}}Buffer:_in():functionName( ... )}}
The 'empty' behavior is different when chained to empty Element-Buffer or an empty child Buffer of an Element-Buffer.
Library methods chained to an empty Buffer which parent is an [[#Element-Buffer|Element-Buffer object]] will instead string the grandparent [[#Buffer-HTML|Buffer-HTML object]] for use as the first argument before appending the result to the new Buffer. This interface is provided because Buffer-HTML objects, which are not true Buffer objects, are unable to load these functions, making this the only chainable option for Scribunto methods that includes the outer tag of non-empty Element-Buffers.
Chained on an empty Element-Buffer, these methods will string the Buffer object which created its HTML tree via {{luaself|:_inHTML}}<ref group="note">Though this strings the same object returned by {{luaself|\-HTML:getParent}}, that function is not used to avoid setting a "lastHTML" reference.</ref> and append the result to the Element-Buffer.<ref group=example>Compare the comment and source:
{{#tag:syntaxhighlight|--[[--= Result: ===>
This is just a quick example to demonstrate a neat concept:
Line 967 ⟶ 693:
'I hope such', 'much', 'your liking')--B
:gsub('trick.', 'concept:\n')|lang=lua}}
==Modified {{code|..}} operator==
All "true" Buffer objects{{--}}e.g., the [[#Buffer object|regular]], [[#Stream-Buffer|stream]], and [[#Element-Buffer|element]] varieties{{--}}share the same {{luaref|metatables|__concat metamethod|y}}. Some Buffer-''like'' classes, namely {{luaself|\-HTML object|plain=y}}s and the {{luaself|\-nil object|plain=y}}, also have this same metamethod.
The extended {{luaref|Concatenation operator|..}} operator does not append to Buffer objects. In other words, Buffers generally remain the same as before the op excepting those effects that apply whenever Buffers are strung (See {{luaself|.last_concat|plain=y}}, {{luaself|stream mode|plain=y}}, and {{luaself|\-variable|plain=y}}).
===with non-tables===
{{code|lang=lua|Buffer .. value}}
{{code|lang=lua|value .. Buffer}}
Any non-table <code>value</code> may be joined a Buffer object with the concatenation operator {{code|lang=lua|..}} without error.
With the exception of Element-Buffers (which are a special case), the op passes each object, ordered left-to-right, to {{luaself|:_}} which inserts [[#valid|valid]]ated items in a new table, which this returns through {{luaref|table.concat||y}}.
Concatenating an [[#valid|invalid]] ''value'' and a Buffer has generally the same effect as {{luaref|tostring|args=Buffer}} unless such involves:
Line 995 ⟶ 714:
===with tables===
{{code|lang=lua|Buffer .. table}}
{{code|lang=lua|table .. Buffer}}
The same general operation applies for tables as with non-tables{{--}}i.e., [[#valid|validated]] values are inserted left-to-right into a new table to be joined by table.concat. In fact, tables which have a metatable (including Buffer objects which are not an Element-Buffer) are forwarded to Buffer:_ and processed the same way as non-tables.
Given a <code>table</code> for which {{luaref|getmetatable||y}} returns nil or false, this instead forwards the table to {{luaself|:_all}}, which iterates every value indexed at a number key in sequential order, inserting those which are valid in the new table.
As a reminder, Buffer:_ validates tables with metatables that lack a __tostring method through table.concat, which throws an error on sequences containing one or more value that is neither a string nor a number. Such accounts for nearly all cases of breaking errors involving this op.
Note that the ''valKey'' parameter of Buffer:_all is not triggered.
===for Element-Buffers===
{{code|lang=lua|Element-Buffer .. value}}
{{code|lang=lua|value .. Element-Buffer}}
{{code|lang=lua|Element-Buffer .. Element-Buffer}}
To recap and expand upon [[#Element-Buffer|§ Element-Buffer-object]], the behavior of this op depends on whether its parent Buffer-HTML is {{luaref|mw.html.create|selfClosing|y}} or if the other ''value'' is also an Element-Buffer. Also, the final result always includes the outer HTML object (i.e., the tag) in some manner.
For Element-Buffers of "open" tags, this op creates a table with a metaindex that references the parent of the Element-Buffer. The table is then effectively a "mirror" of the parent Buffer-HTML object except that it contains an empty table at <code>table.nodes</code>{{--}} the index of the Element-Buffer within its parent. This then populates the mirror's inner table with the string of the Element-Buffer and the other value, validated left-to-right, in a manner not unlike what this does with the temporary table it creates when concatenating non-element Buffers to another value. This then returns the mirror table through the __tostring metamethod of the mw.html library, yielding a string which resembles that of the parent tag but with ''value'' inserted in front of or behind the original inner text depending on whether ''value'' was to the left or right of the <code>..</code> operator, respectively.
When the selfClosing property of the parent evaluates true, this operates on the parent instead of the Element-Buffer{{--}}i.e., the resulting string will have ''value'' on the outside as opposed to within the tag (placing it inside would be pointless since selfClosing tags do not show inner contents).
If both operated objects are Element-Buffers, this mirrors the parent of the first. The inner table of the mirror is then populated by inserting the string of the first Element-Buffer followed by the string the parent Buffer-HMTL of the second. The resulting string would be as though the parent of the second were the last node of the first parent. Note that this Element-to-Element rule does not apply when the first Buffer belongs to a selfClosing tag (in which case, this behaves as though the selfClosing parent were to the left of the operator, returning a string with the selfClosing tag inside the tag of the second Element-Buffer in front the latter's inner contents.)
Finally, this combines an Element-Buffer and a table ''value'' which has no metatable by passing the table as ''args'' for {{luaself|pre=Element-|:_add}} with the mirror of the Element-Buffer as the "self". This avoids permanently changing the parent Buffer-HTML by setting a new table at <code>table.attributes</code> or <code>table.styles</code> in the mirror the first time methods such as {{luaref|mw.html:css|plain=y}}, {{luaref|mw.html:attr|plain=y}}, {{luaref|mw.html:addClass|plain=y}}, etc. attempt to access those tables, copying the original's via the recursive form of {{luaself|:_cc}}. Note however that permanent changes may be made to other objects whenever methods such as via {{luaself|args.done}} or {{luaself|args.globalFunction}} are keyed to navigate beyond the mirror or "sandbox".
{{anchor|MBpairs}}
==require'Module:Buffer'.__pairs==
[[#MBpairs|{{code|lang=lua|require'Module:Buffer'.__pairs( table, flag, ext )}}]]
Returns two values: an iterator function and the <code>table</code>. This is intended for use in the {{luaref|iterators|iterator form of|y}} <code>for</code>.
One distinctive feature of this pairs method is that it splits keys into two groups: {{luaref|number||y}}s and non-numbers. This indexes each group of keys in its own "map" object, traversed by its own iterator function{{--}}i.e, iterating both sets of keys requires two separate for loops. Numeric keys are served in an orderly fashion as with {{luaref|ipairs}} except that those which are negative, non-consecutive, and non-integer may be included. Moreover, this can find some keys paired with explicitly nil values.<ref group="example">Take a moment to look at the following tables ''X'' and ''Y'':
{{#tag:syntaxhighlight|local X = { [5] = 5 }
local Y = { nil, nil, nil, nil, 5 }
|lang=lua}}
These tables are indistinguishable to {{luaref|ipairs}} and {{luaref|pairs}} (ipairs iterates nothing and pairs yields only one key-value pair for either table).
While this module's __pairs method also gives only one pair for table ''X'', it loops all five explicitly declared indicies for table ''Y'', as shown in the console input below with Module:Buffer as ''p'':
5 5
for k, v in p.__pairs{ nil, nil, nil, nil, 5 } do mw.log(k, v) end
Line 1,072 ⟶ 765:
4 nil
5 5|lang=lua}}
</ref>
The <code>flag</code> argument selects the iterator method returned for that loop. When ''flag'' is an explicit nil or omitted, this returns an iterator for number keys. If given any non-nil ''flag'' (i.e., false or any value that evaluates true), this returns a method for looping non-numeric keys. Because both sets are mapped at the same time, you may avoid a redundant mapping op in a subsequent loop by passing an explicit nil or false as ''flag''{{--}}i.e., omitting ''flag'' or passing true indicate that re-mapping is desired.
This automatically selects certain tables for "mapless" iteration. Typically, mapless differs from mapped only in that it uses fewer server resources, though, as explained in the next section on mapping, it may "miss" keys in some cases.
Mapping behavior may be modified or extended by <code>ext</code>. To disable mapless iteration for the table, you may pass false as ''ext''. If not nil or false, ''ext'' must be a pairs method that takes the table as its only argument and returns a function that may iterate its keys for mapping purposes. Note that re-mapping avoidance via ''flag'' does not apply if ''ext'' is explicitly given, though a nil ''ext'' does not disqualify a table from mapless iteration.
{{anchor|mapping}}
===Mapping process===
Tables are mapped in two stages.
The initial stage is a {{luaref|for|numerical for loop|y}} which inserts integers between {{code|lang=lua|1}} and {{code|lang=lua|#table}} in the number key map. Because nothing is checked in this step, this may map keys which the [[#Iterators|numeric map iterator]] would pair with nil values or with values from the table's {{luaref|Metatables|meta __index|y}}.
The second stage explores the table's keys with an {{luaref|iterators|iterative for loop|y}} and {{luaref|next|next, table}} as the default ''expression-list'', or, if ''ext'' evaluates true, the expression returned by {{code|lang=lua|ext( table )}}. This ignores keys already mapped in the first stage and checks if any unmapped key is a number before indexing it in the appropriate map group. Upon completion, if any new number key were found in the second stage, this runs the numeric map through {{luaref|table.sort||y}}. No order is imposed on the non-numeric map.
Alternatively, a table may qualify for "mapless" iteration if {{luaref|rawget|args=table, 1}} is not nil, and {{luaref|next|args=table, #table}} returns nil. If either ''flag'' or ''ext'' are not nil, or if the table was previously mapped, such permanently disqualifies a table for mapless processing.
As a side note, if mapless numeric iteration occurs, this returns {{code|lang=lua|iterator, table, nil}}. In other words, you may use {{luaref|select}} to confirm that the table qualifies for mapless iteration when it has a third explicit return (for debugging).
===Iterators===
{{luaself|iterator|args=table, key}}
One of four functions may be provided in the ''{{luaref|iterators|expression-list|y}}'' returned by this pairs method, depending on which group of keys (numeric or non-numeric) and which iteration process (map-based or mapless) is indicated.
When <code>key</code> is nil or unspecified, map iterators will return the key object referenced by the first index of the relevant map along with the value it indexes. If passed the first mapped key, these iterators then return the second index mapped, which if passed in turn may retrieve the third and so on until the last mapped key has been served.
For numeric iteration, the mapless method returns {{code|lang=lua|1, table[1]}} when ''key'' is unspecified. If a ''key'' is given, it returns {{code|lang=lua|key + 1, table[ key + 1 ]}} unless ''key'' is greater or equal to the length of the table, upon which it returns nil. For non-numeric keys, the mapless "iterator" is actually a no-op (empty) function which takes nothing, does nothing, and returns nothing{{--}}provided only to prevent an error when the for loop expects a function.
As mentioned (using different words), key-value pairs are served independently of whether or not {{code|lang=lua|table[key]}} exists and retrieved without using {{luaref|rawget}}.
For example, take a look at table ''x'' as declared in the following statement: {{code|lang=lua|local x = {1,nil,nil,nil,nil,nil,nil,8} }}. Table ''x'' has a length equal to 8. With ipairs, the for loop stops after the first pair. In contrast, this module's __pairs method will loop all 8 keys declared{{--}}i.e., (1, 1), (2, nil), ... (7, nil), (8, 8). That said, this only iterates two keys if table ''x'' were declared as {{code|lang=lua|{ 1, [8] = 8} }} instead even though such is indistinguishable to Finally, the loop would continue to include any keys set to nil after the mapping process.</ref>
You may assign these iterators to a local variable to use them directly. If an unmapped table is given to a map iterator, it will forward the table to this pairs method for immediate mapping. Though no map table is produced for the mapless iteration, the pairs method does cache the length of the table at a map reference, which the iterator compares against ''key'' to determine when to stop. Unlike the map methods, the mapless iterator does not call the pairs method when such has been bypassed and instead compares ''key'' to the value returned by the {{luaref|length operator||y}}, which may be unstable if the loop includes code that sets or unsets indicies within the table. Also, the mapless method will throw an error if given a table that has been mapped (when it attempts to compare ''key'' to a map object).
==Appendix==
{{anchor|tips|Tips}}
===Tips and style recommendations===
* If [[#Buffer|joining Buffer]] with a string immediately after <code>:_'<i>text</i>'</code>, place a space between 'string' and the [[#Buffer|separator]] and use double/single quote marks to . (i.e. <code>:_'<i>text</i>' " "</code> instead of <code>:_'<i>text</i>'{{`}} '</code> or <code>:_'<i>text</i>'(' ')</code>)
Line 1,151 ⟶ 810:
* Treat {{code|:_}} as though it were a {{code|..}} op. Wrapping strings with unnecessary {{code|()}} is akin to {{code|( 'string1' ) .. ( 'string2' ) .. ( 'string3' )}}.
* To insert an empty string as a placeholder for a [[#Buffer|separator]] without setting {{code|raw}}, pass a table containing only an empty string, like so: {{luaself|:_|args={''} }}.
* Raw appending a non-table is pointless since no other Scribunto type can tostring differently afterwards. However, this developer believes you are smart enough that {{code|lang=lua|1=raw and type(v)=='table'}} is a waste of server resources. (Such checks are why {{luaref|mw.html:wikitext||y}} takes twice as much time to append a list of strings as {{luaself|pre=Stream-|:each|plain=y}} despite their near-identical roles in an Element-Stream-Buffer).
Line 1,168 ⟶ 826:
* If the table reference passed as {{code|clear}} was appended [[#raw|raw]] in multiple positions, this is akin to performing {{luaself|:_nil}} at all positions simultaneously. (May be easier than trying to come up with a {{luaref|string.gsub}} pattern)
* Inserting a [[#Buffer:_G|named]] empty table is raw as a placeholder to be populated later via this function may be easier than calculating ''pos'' argument of {{luaself|:_}}.
===Examples===
{{reflist|group=example}}
===Notes===
Non-literal interpretations of the source code (that is, more opinion than fact) are provided here to offer additional clarity. Overly technical details may be found here as well when including such caveats appears more likely to confuse than help those advanced-but-not-quite-fluent in Lua.
{{reflist|group=note}}
Line 1,204 ⟶ 842:
[[Category:Lua metamodules]]
}}</includeonly>
<noinclude>
[[Category:Module documentation pages]]
</noinclude>
| |||