wikimedia/mediawiki-extensions-Cite
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/Cite synced 2024-11-28 17:00:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Cite/js/lib/ext.Cite.js

441 lines
12 KiB
JavaScript
Raw Normal View History

Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
/* ----------------------------------------------------------------------
* This file implements <ref> and <references> extension tag handling
* natively in Parsoid.
* ---------------------------------------------------------------------- */
Deep-freeze cache returns and enable strict mode This exposed a few bugs (primarily missing var declarations), which are fixed. It would for example have caught the shallow clone bug we just fixed, and should catch similar bugs early in the future. TODO / issues this exposed: Avoid attempted tsr modification in ext.core.TemplateHandler.js:306:29. This is fixed for now by cloning the tokens, but should really be avoided by stripping the tsr before caching the tokens (anything in phase 1 will work for example). Change-Id: I6a1a07de7ac333f31da9cf0ae9ed20e5507bacba
2012-10-30 00:51:07 +00:00
"use strict";
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
var Util = require( './mediawiki.Util.js' ).Util,
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
DU = require( './mediawiki.DOMUtils.js').DOMUtils,
Fix a bunch of jshint warnings. Most of these warnings are globals defined in mediawiki.parser.defines.js, which we turn into proper local variables. But there are a grab page of other use-before-def, missing semicolon, bad line break, and other minor warnings. No tricky stuff attempted in this patch, this should be safe obvious fixes only... although there is a nasty circular dependency between Util and parser.defines which had to be broken. Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
2013-04-22 19:51:09 +00:00
defines = require('./mediawiki.parser.defines.js'),
Replace jquery dependency with a minimal 'fakejquery'. The 'fakejquery' module just defines the bits we use: $.each, $.map, $.extend, $.isArray, $.isEmptyObject (and the internal functions required to implement those). Change-Id: I626b2f3a3d3a8d395d0c9679e01d3399403636dd
2013-02-15 21:25:14 +00:00
$ = require( './fakejquery' );
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
Fix a bunch of jshint warnings. Most of these warnings are globals defined in mediawiki.parser.defines.js, which we turn into proper local variables. But there are a grab page of other use-before-def, missing semicolon, bad line break, and other minor warnings. No tricky stuff attempted in this patch, this should be safe obvious fixes only... although there is a nasty circular dependency between Util and parser.defines which had to be broken. Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
2013-04-22 19:51:09 +00:00
// define some constructor shortcuts
var KV = defines.KV,
Remove unused variables. 'jshint --show-non-errors' shows unused variables. Some of these are unused function arguments, which are rarely bugs. But try to fix the ones which are forgotten/dead code and unnecessary require()s. Change-Id: I685ccd8e388fd3acf75053a07e2f729398fa2855
2013-04-25 13:43:49 +00:00
SelfclosingTagTk = defines.SelfclosingTagTk;
Forward-port Cite extension * Adapted Cite extension to use current interfaces and token formats * Improved TokenCollector Change-Id: I20419b19edd9bbad2c2abf17a2ff1411b99c0c04
2012-05-03 11:05:28 +00:00
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
// FIXME: Move out to some common helper file?
// Helper function to process extension source
function processExtSource(manager, extToken, opts) {
var extSrc = extToken.getAttribute('source'),
tagWidths = extToken.dataAttribs.tagWidths,
content = extSrc.substring(tagWidths[0], extSrc.length - tagWidths[1]);
// FIXME: Should this be specific to the extension
// or is it okay to do this unconditionally for all?
// Right now, this code is run only for ref and references,
// so not a real problem, but if this is used on other extensions,
// requires addressing.
//
// Strip white-space only lines
var wsMatch = content.match(/^((?:\s*\n)?)((?:.|\n)*)$/),
leadingWS = wsMatch[1];
// Update content to normalized form
content = wsMatch[2];
if (!content || content.length === 0) {
opts.emptyContentCB(opts.res);
} else {
// Pass an async signal since the ext-content is not processed completely.
opts.parentCB({tokens: opts.res, async: true});
// Pipeline for processing ext-content
var pipeline = manager.pipeFactory.getPipeline(
opts.pipelineType,
Util.extendProps({}, opts.pipelineOpts, {
wrapTemplates: true,
// SSS FIXME: Doesn't seem right.
// Should this be the default in all cases?
inBlockToken: true
})
);
// Set source offsets for this pipeline's content
var tsr = extToken.dataAttribs.tsr;
pipeline.setSourceOffsets(tsr[0]+tagWidths[0]+leadingWS.length, tsr[1]-tagWidths[1]);
// Set up provided callbacks
if (opts.chunkCB) {
pipeline.addListener('chunk', opts.chunkCB);
}
if (opts.endCB) {
pipeline.addListener('end', opts.endCB);
}
if (opts.documentCB) {
pipeline.addListener('document', opts.documentCB);
}
// Off the starting block ... ready, set, go!
pipeline.process(content);
}
}
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
/**
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
* Simple token transform version of the Ref extension tag
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
*
Clean up and comment the Cite extension a bit.
2011-12-13 18:45:09 +00:00
* @class
* @constructor
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
*/
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
function Ref(cite) {
this.cite = cite;
this.reset();
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
}
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
/**
* Reset state before each top-level parse -- this lets us share a pipeline
* to parse unrelated pages.
*/
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
Ref.prototype.reset = function() { };
Reset the Cite extension state with the end token This should hopefully fix some spurious semantic diffs that are purely based on ref numbering, which changes if the references are not reset. Change-Id: I37b1f4cfe69538e1c5ccc81fdad3084c01151700
2012-11-16 18:03:01 +00:00
Clean up and comment the Cite extension a bit.
2011-12-13 18:45:09 +00:00
/**
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
* Handle ref tokens
Clean up and comment the Cite extension a bit.
2011-12-13 18:45:09 +00:00
*/
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
Ref.prototype.handleRef = function ( manager, pipelineOpts, refTok, cb ) {
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
var inReferencesExt = pipelineOpts.extTag === "references",
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
refOpts = $.extend({ name: null, group: null }, Util.KVtoHash(refTok.getAttribute("options"))),
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
about = inReferencesExt ? '' : "#" + manager.env.newObjectId(),
finalCB = function(toks, content) {
// Marker meta with ref content
var da = Util.clone(refTok.dataAttribs);
// Clear stx='html' so that sanitizer doesn't barf
da.stx = undefined;
Improved template roundtripping based on WT ranges on DOM nodes. - Fixed several bugs in the DSR computation. - Deleted comment tokens from template output. - Eliminated TSR info from template output. - Rearranged order of DOM post passes. - Updated template encapsulation to use DSR values. - There are still a few missing pieces and scenarios that are not handled properly. Change-Id: I644914902ec1d27418138b107abe765f81178398
2012-09-17 19:46:44 +00:00
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
toks.push(new SelfclosingTagTk( 'meta', [
Add capability for DOM-based template expansion, and use DOM fragments for extensions This patch adds the capability to expand individual transclusions all the way to DOM, which enforces properly nested templates. This is also needed for DOM-based template re-expansion, which the VE folks would like to use for template editing. In normal parsing, DOM-based expansion is currently disabled by default for transclusions, and enabled by default for extensions. The decision whether to balance a particular transclusion can be based on a statistics-based classification of templates into balanced and unbalanced ones. The advantage of this approach is consistency in behavior for old revisions. Another alternative is to wrap unbalanced transclusions into <domparse> tags which disable DOM-based parsing for all transclusions in its content. This has the advantage that all special cases can be handled after tag insertion, and that balancing could also be enforced in the PHP parser using an extension. Other major changes: * Renamed transclusion content typeof from mw:Object/Template to mw:Transclusion * Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo and switched Cite to use lower-case ref/references too Other minor changes: * Only apply template encapsulation algorithm on DOM to mw:Transclusion and mw:Param objects, and no longer to all mw:Object/* elements. We should probably switch to a more explicit encapsulation type instead. Maybe something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion instead of the current mw:Transclusion and mw:Transclusion/End, so that stripping those metas out selectively is easy? * Changed the DOMTraverser logic to let handlers explicitly return the next element to handle. Useful when several siblings are handled, as is the case for the fragment unwrapper for example, and avoids some cases where deleted nodes were still being processed. * Changed Cite to use mw:Extension/Ref{,erences} as all other extensions. * Make sure we round-trip gallery when the PHP preprocessor is not used Five parsoid-specific wt2html tests are failing due to the typeof change. They will be fine once those tests are adjusted. For now, adding them to parser tests blacklist. TODO: * Switch the Cite extension to the generic DOMFragment mechanism instead of marker tokens. Change-Id: I64b560a12695256915d2196d0646347381400e80
2013-05-16 22:23:05 +00:00
new KV('typeof', 'mw:Extension/ref/Marker'),
new KV('about', about),
new KV('group', refOpts.group || ''),
new KV('name', refOpts.name || ''),
new KV('content', content || ''),
new KV('skiplinkback', inReferencesExt ? 1 : 0)
], da));
RT <references> as well as </references> tag. * Fixes RT diff in en:Standing Sushi Bar. Change-Id: Ia05f9d01503e3003260a10663d1dd845a261beab
2012-11-16 23:36:07 +00:00
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
// All done!
cb({tokens: toks, async: false});
};
RT <references> as well as </references> tag. * Fixes RT diff in en:Standing Sushi Bar. Change-Id: Ia05f9d01503e3003260a10663d1dd845a261beab
2012-11-16 23:36:07 +00:00
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
processExtSource(manager, refTok, {
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
// Full pipeline for processing ref-content
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
pipelineType: 'text/x-mediawiki/full',
pipelineOpts: {
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
extTag: "ref"
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
},
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
res: [],
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
parentCB: cb,
emptyContentCB: finalCB,
documentCB: function(refContentDoc) {
finalCB([], refContentDoc.body.innerHTML);
}
});
};
Added a new parsing pipeline for processing ref tokens. * Added a tokens/x-mediawiki/post-expansion sub-pipeline that is used to process ref-content. This same pipeline type could also be used to post-process tokenized content from other extensions. * Cleaned up transform handler ranks a bit. * Fixed paragraph-handler to accept initial state and also fixed it to do a complete reset on encountering EOFTk. Cite ref-content handling uses the sub-pipeline while passing the inBlockToken flag to prevent top-level p-wrapping of ref-content. * Fixes references output on en:Barack Obama and introduces lists in individual ref items. * No change in parser tests -- how do we add tests for testing extensions like cite/ref? Change-Id: I928a3a0f5f989ec28bbe73383794fe6f32599fd1
2012-11-29 20:09:06 +00:00
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
/**
* Helper class used by <references> implementation
*/
function RefGroup(group) {
this.name = group || '';
this.refs = [];
this.indexByName = {};
}
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
RefGroup.prototype.add = function(refName, about, skipLinkback) {
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
// NOTE: prefix name with "ref:" before using it as a property key
// This is to avoid overwriting predefined keys like 'constructor'
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
var ref;
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
if (refName && this.indexByName["ref:" + refName]) {
ref = this.indexByName["ref:" + refName];
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
} else {
var n = this.refs.length,
refKey = (1+n) + '';
if (refName) {
refKey = refName + '-' + refKey;
}
ref = {
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
about: about,
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
content: null,
group: this.name,
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
groupIndex: (1+n), // FIXME -- this seems to be wiki-specific
index: n,
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
key: refKey,
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
linkbacks: [],
name: refName,
target: 'cite_note-' + refKey
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
};
this.refs[n] = ref;
if (refName) {
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
this.indexByName["ref:" + refName] = ref;
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
}
}
if (!skipLinkback) {
ref.linkbacks.push('cite_ref-' + ref.key + '-' + ref.linkbacks.length);
}
return ref;
};
RefGroup.prototype.renderLine = function(refsList, ref) {
var ownerDoc = refsList.ownerDocument,
arrow = ownerDoc.createTextNode('↑'),
li, a;
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
// Generate the li and set ref content first, so the HTML gets parsed.
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
// We then append the rest of the ref nodes before the first node
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
li = ownerDoc.createElement('li');
DU.addAttributes(li, {
'about': "#" + ref.target,
'id': ref.target
});
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
li.innerHTML = ref.content;
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
// If ref-content has block nodes, wrap it in a div, else in a span
var contentNode = ownerDoc.createElement(DU.hasBlockContent(li) ? 'div' : 'span');
// Move all children from li to contentNode
DU.migrateChildren(li, contentNode);
li.appendChild(contentNode);
// 'mw:referencedBy' span wrapper
var span = ownerDoc.createElement('span');
span.setAttribute('rel', 'mw:referencedBy');
li.insertBefore(span, contentNode);
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
// Generate leading linkbacks
if (ref.linkbacks.length === 1) {
a = ownerDoc.createElement('a');
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
DU.addAttributes(a, {
'href': '#' + ref.linkbacks[0]
});
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
a.appendChild(arrow);
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
span.appendChild(a);
// Space between span-wrapper and content node
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
li.insertBefore(ownerDoc.createTextNode(' '), contentNode);
} else {
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
span.appendChild(arrow);
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
$.each(ref.linkbacks, function(i, linkback) {
a = ownerDoc.createElement('a');
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
DU.addAttributes(a, {
'href': '#' + ref.linkbacks[i]
});
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
a.appendChild(ownerDoc.createTextNode(ref.groupIndex + '.' + i));
// Separate linkbacks with a space
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
span.appendChild(ownerDoc.createTextNode(' '));
span.appendChild(a);
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
});
}
// Add it to the ref list
refsList.appendChild(li);
};
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
function References(cite) {
this.cite = cite;
this.reset();
}
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
References.prototype.reset = function(group) {
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
// NOTE: prefix name with "refgroup:" before using it as a property key
// This is to avoid overwriting predefined keys like 'constructor'
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
if (group) {
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
this.refGroups["refgroup:" + group] = undefined;
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
} else {
this.refGroups = {};
}
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
};
Improved template roundtripping based on WT ranges on DOM nodes. - Fixed several bugs in the DSR computation. - Deleted comment tokens from template output. - Eliminated TSR info from template output. - Rearranged order of DOM post passes. - Updated template encapsulation to use DSR values. - There are still a few missing pieces and scenarios that are not handled properly. Change-Id: I644914902ec1d27418138b107abe765f81178398
2012-09-17 19:46:44 +00:00
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
/**
* Sanitize the references tag and convert it into a meta-token
*/
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
References.prototype.handleReferences = function ( manager, pipelineOpts, refsTok, cb ) {
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
refsTok = refsTok.clone();
Handle multiply-referenced ref-tags without duplicate ref-content. * When named-ref-tags are used multiple times in a document, the Cite.onReferences function was outputting the ref-content once for each use in the references section. While this is "harmless" for regular ref-content, when the ref-content has templates (ex: {[cite .. }}), that template content is duplicated several times -- this also means that template expansions seen in the output no longer has unique ids. Occasionally, this trips up DOM passes (template encapsulation) which make the reasonable assumption that template ids are unique. It introduced an infinite loop in the code that detects template range nestings and overlaps. This is not triggered always, but only in certain scenarios. en:Euphoria (Enrique Iglesias album) was a page that sent the parser into an infinite loop. * Now fixed by outputting ref-content once. * In addition, added an error-check in the DOM post-pass that might get stuck in an infinite loop to output an error message. * No change in parser test results. * en:Euphoria (Enrique Iglesias album) now parses and rts without getting stuck in an infinite loop. Possibly other pages as well. Change-Id: I81a055999eefe3ca36dfb8a9cda3fee538ae6c65
2013-02-20 23:50:52 +00:00
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
// group is the only recognized option?
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
var refsOpts = Util.KVtoHash(refsTok.getAttribute("options")),
group = refsOpts.group;
Make Cite <references> group attribute handling more robust The PHP preprocessor returns a references tag with an empty group attribute, which we did not map to the null reference group. This caused the references listing to vanish when using the PHP preprocessor. This patch makes sure the attribute is converted to a string, stripped of leading/trailing whitespace and finally set to null if no string remains. No changes in parser tests, since Cite is in a separate extension. Change-Id: Ib3de375225947a78c362370be8d78504fa24def2
2012-11-27 23:13:32 +00:00
if ( group && group.constructor === Array ) {
// Array of tokens, convert to string.
group = Util.tokensToString(group);
}
// Point invalid / empty groups to null
Fixed #tag parser function. * Updated #tag parser function code to set tag attributes. This lets {{Reflist|group=n}} to pass the group=n attribute to the <references> tag. In turn, this fixes incorrect reference listing in the above template call. This then fixes crashers in en:Prophet Muhammed, en:The PS3 and such pages. - TODO: parser output for Prophet Muhammed is still broken where content from body ends up in a table that has display:none css set. * Minor code cleanup in AttributeTransformManager.process and added comment about lazy processing. Change-Id: If528a3a5c6e22d3ff691dfc6b5b2f00201a26384
2012-11-29 16:15:51 +00:00
if ( ! group ) {
Make Cite <references> group attribute handling more robust The PHP preprocessor returns a references tag with an empty group attribute, which we did not map to the null reference group. This caused the references listing to vanish when using the PHP preprocessor. This patch makes sure the attribute is converted to a string, stripped of leading/trailing whitespace and finally set to null if no string remains. No changes in parser tests, since Cite is in a separate extension. Change-Id: Ib3de375225947a78c362370be8d78504fa24def2
2012-11-27 23:13:32 +00:00
group = null;
}
Cleanup: Fixed some comments, formatting, removed dead code * No change in functionality or parser test results. Change-Id: I66a7b1f2a1618d0809d6783156fcc6bc89b44885
2013-04-25 10:40:33 +00:00
// Emit a placeholder meta for the references token
// so that the dom post processor can generate and
// emit references at this point in the DOM.
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
var emitMarkerMeta = function() {
var marker = new SelfclosingTagTk('meta', refsTok.attribs, refsTok.dataAttribs);
marker.dataAttribs.stx = undefined;
DU.addAttributes(marker, {
'about': '#' + manager.env.newObjectId(),
'group': group,
Add capability for DOM-based template expansion, and use DOM fragments for extensions This patch adds the capability to expand individual transclusions all the way to DOM, which enforces properly nested templates. This is also needed for DOM-based template re-expansion, which the VE folks would like to use for template editing. In normal parsing, DOM-based expansion is currently disabled by default for transclusions, and enabled by default for extensions. The decision whether to balance a particular transclusion can be based on a statistics-based classification of templates into balanced and unbalanced ones. The advantage of this approach is consistency in behavior for old revisions. Another alternative is to wrap unbalanced transclusions into <domparse> tags which disable DOM-based parsing for all transclusions in its content. This has the advantage that all special cases can be handled after tag insertion, and that balancing could also be enforced in the PHP parser using an extension. Other major changes: * Renamed transclusion content typeof from mw:Object/Template to mw:Transclusion * Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo and switched Cite to use lower-case ref/references too Other minor changes: * Only apply template encapsulation algorithm on DOM to mw:Transclusion and mw:Param objects, and no longer to all mw:Object/* elements. We should probably switch to a more explicit encapsulation type instead. Maybe something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion instead of the current mw:Transclusion and mw:Transclusion/End, so that stripping those metas out selectively is easy? * Changed the DOMTraverser logic to let handlers explicitly return the next element to handle. Useful when several siblings are handled, as is the case for the fragment unwrapper for example, and avoids some cases where deleted nodes were still being processed. * Changed Cite to use mw:Extension/Ref{,erences} as all other extensions. * Make sure we round-trip gallery when the PHP preprocessor is not used Five parsoid-specific wt2html tests are failing due to the typeof change. They will be fine once those tests are adjusted. For now, adding them to parser tests blacklist. TODO: * Switch the Cite extension to the generic DOMFragment mechanism instead of marker tokens. Change-Id: I64b560a12695256915d2196d0646347381400e80
2013-05-16 22:23:05 +00:00
'typeof': 'mw:Extension/references/Marker'
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
});
cb({ tokens: [marker], async: false });
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
};
processExtSource(manager, refsTok, {
// Partial pipeline for processing ref-content
// Expand till stage 2 so that all embedded
// ref tags get processed
pipelineType: 'text/x-mediawiki',
pipelineOpts: {
extTag: "references",
wrapTemplates: pipelineOpts.wrapTemplates
},
res: [],
parentCB: cb,
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
emptyContentCB: emitMarkerMeta,
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
chunkCB: function(chunk) {
// Extract ref-content tokens and discard the rest
var res = [];
for (var i = 0, n = chunk.length; i < n; i++) {
var t = chunk[i];
if (t.constructor === SelfclosingTagTk &&
t.name === 'meta' &&
Add capability for DOM-based template expansion, and use DOM fragments for extensions This patch adds the capability to expand individual transclusions all the way to DOM, which enforces properly nested templates. This is also needed for DOM-based template re-expansion, which the VE folks would like to use for template editing. In normal parsing, DOM-based expansion is currently disabled by default for transclusions, and enabled by default for extensions. The decision whether to balance a particular transclusion can be based on a statistics-based classification of templates into balanced and unbalanced ones. The advantage of this approach is consistency in behavior for old revisions. Another alternative is to wrap unbalanced transclusions into <domparse> tags which disable DOM-based parsing for all transclusions in its content. This has the advantage that all special cases can be handled after tag insertion, and that balancing could also be enforced in the PHP parser using an extension. Other major changes: * Renamed transclusion content typeof from mw:Object/Template to mw:Transclusion * Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo and switched Cite to use lower-case ref/references too Other minor changes: * Only apply template encapsulation algorithm on DOM to mw:Transclusion and mw:Param objects, and no longer to all mw:Object/* elements. We should probably switch to a more explicit encapsulation type instead. Maybe something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion instead of the current mw:Transclusion and mw:Transclusion/End, so that stripping those metas out selectively is easy? * Changed the DOMTraverser logic to let handlers explicitly return the next element to handle. Useful when several siblings are handled, as is the case for the fragment unwrapper for example, and avoids some cases where deleted nodes were still being processed. * Changed Cite to use mw:Extension/Ref{,erences} as all other extensions. * Make sure we round-trip gallery when the PHP preprocessor is not used Five parsoid-specific wt2html tests are failing due to the typeof change. They will be fine once those tests are adjusted. For now, adding them to parser tests blacklist. TODO: * Switch the Cite extension to the generic DOMFragment mechanism instead of marker tokens. Change-Id: I64b560a12695256915d2196d0646347381400e80
2013-05-16 22:23:05 +00:00
/^mw:Extension\/ref\/Marker$/.test(t.getAttribute('typeof')))
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
{
res.push(t);
}
}
// Pass along the ref toks
cb({ tokens: res, async: true });
},
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
endCB: emitMarkerMeta
Updated native <ref> and <references> tag implementations. * Updated native implementations of the <ref> and <references> tag implementations of the cite extension. * <references> tag was not being processed properly by Parsoid. This led to lost references on the BO page. This patch fixes it which fills out references and more closely matches output en:WP. * Extracted extension content processing code into a helper and reused it for both <ref> and <references> handler. - Leading ws-only lines are unconditionally stripped. Is this accurate or is this extension-specific? Given that this code is right now tied to <ref> and <references> tag, this is not yet a problem, but if made more generic, this issue has to be addressed. * PreHandler should not run when processing the refs-tag. Right now, this is a hard check in the pre-handler. Probably worth making this more generic by letting every stage in the pipeline get a chance at turning themselves on/off based on the extension being processed by the pipeline (can use the _applyToStage fn. on ParserPipeline). TO BE DONE. * <ref> extension needs to be reset after each <references> tag is processed to duplicate behavior of existing cite extension. TO BE DONE. * Updated refs group index to start at 1. * No change in parser tests. References section output on the en:Barack Obama page now more closely matches the refs output on enwp. * In addition to the en:BO page, the following wikitext was used to fix bugs and test the implementation. CMD: "node parse --extensions ref,references < /tmp/test" ---------------------------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> ---------------------------------------------- Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
2013-03-26 00:40:20 +00:00
});
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
};
References.prototype.extractRefFromNode = function(node) {
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
// NOTE: prefix name with "refgroup:" before using it as a property key
// This is to avoid overwriting predefined keys like 'constructor'
function getRefGroup(refGroups, group) {
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
group = group || '';
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
var key = "refgroup:" + group;
if (!refGroups[key]) {
refGroups[key] = new RefGroup(group);
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
}
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
return refGroups[key];
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
}
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
var group = node.getAttribute("group"),
refName = node.getAttribute("name"),
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
about = node.getAttribute("about"),
skipLinkback = node.getAttribute("skiplinkback") === "1",
(Bug 49490) Prefix ref name/group before using as property key * The page in question "es:Estadio_Deportivo_Cali" had a ref with name "constructor", and this name was used as an object property key and this clashed with the predefined property constructor. * The reliable solution here is to prefix ref-name and ref-group with a string and use it to prevent clashes. Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
2013-06-12 19:26:36 +00:00
refGroup = getRefGroup(this.refGroups, group),
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
ref = refGroup.add(refName, about, skipLinkback);
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
// Add ref-index linkback
if (!skipLinkback) {
var doc = node.ownerDocument,
Minor tweak to data-mw output for <ref name='foo' /> tags * Serializer was complaining about missing source for these tags. Tweaked code to serialize these back to self-closed tag form. * Tested with which rts this with the regular serializer in edit mode. echo "one <ref name='foo'>bar</ref> two<ref name='foo' />\n<references/>" | node parse --extensions ref,references --wt2wt Change-Id: Iaac63b26660d8b03af937d00d04540c3b8c0c86c
2013-05-30 20:22:25 +00:00
span = doc.createElement('span'),
content = node.getAttribute("content");
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
DU.addAttributes(span, {
'about': about,
'class': 'reference',
'data-mw': JSON.stringify({
'name': 'ref',
Minor tweak to data-mw output for <ref name='foo' /> tags * Serializer was complaining about missing source for these tags. Tweaked code to serialize these back to self-closed tag form. * Tested with which rts this with the regular serializer in edit mode. echo "one <ref name='foo'>bar</ref> two<ref name='foo' />\n<references/>" | node parse --extensions ref,references --wt2wt Change-Id: Iaac63b26660d8b03af937d00d04540c3b8c0c86c
2013-05-30 20:22:25 +00:00
// Dont set body if this is a reused reference
// like <ref name='..' /> with empty content.
'body': content ? { 'html': content } : undefined,
(Bug 48808) Serialize edited extension content * Extensions were being serialized back to original wikitext src. * This patch now uses data-mw content to serialize to extension wikitext. * Fixed Cite to add attributes for ref to data-mw so that attributes roundtrip back (WS and quotes are normalized). * TODO: 1. add data-mw for <references> in Cite.js 2. add data-mw for all other extensions in the extension handler Change-Id: If3c35398a409f4775204407b3dcf2442ec2fb4e5
2013-05-25 14:38:13 +00:00
'attrs': {
// Dont emit empty keys
'group': group || undefined,
'name': refName || undefined
}
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
}),
'id': ref.linkbacks[ref.linkbacks.length - 1],
'rel': 'dc:references',
Add capability for DOM-based template expansion, and use DOM fragments for extensions This patch adds the capability to expand individual transclusions all the way to DOM, which enforces properly nested templates. This is also needed for DOM-based template re-expansion, which the VE folks would like to use for template editing. In normal parsing, DOM-based expansion is currently disabled by default for transclusions, and enabled by default for extensions. The decision whether to balance a particular transclusion can be based on a statistics-based classification of templates into balanced and unbalanced ones. The advantage of this approach is consistency in behavior for old revisions. Another alternative is to wrap unbalanced transclusions into <domparse> tags which disable DOM-based parsing for all transclusions in its content. This has the advantage that all special cases can be handled after tag insertion, and that balancing could also be enforced in the PHP parser using an extension. Other major changes: * Renamed transclusion content typeof from mw:Object/Template to mw:Transclusion * Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo and switched Cite to use lower-case ref/references too Other minor changes: * Only apply template encapsulation algorithm on DOM to mw:Transclusion and mw:Param objects, and no longer to all mw:Object/* elements. We should probably switch to a more explicit encapsulation type instead. Maybe something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion instead of the current mw:Transclusion and mw:Transclusion/End, so that stripping those metas out selectively is easy? * Changed the DOMTraverser logic to let handlers explicitly return the next element to handle. Useful when several siblings are handled, as is the case for the fragment unwrapper for example, and avoids some cases where deleted nodes were still being processed. * Changed Cite to use mw:Extension/Ref{,erences} as all other extensions. * Make sure we round-trip gallery when the PHP preprocessor is not used Five parsoid-specific wt2html tests are failing due to the typeof change. They will be fine once those tests are adjusted. For now, adding them to parser tests blacklist. TODO: * Switch the Cite extension to the generic DOMFragment mechanism instead of marker tokens. Change-Id: I64b560a12695256915d2196d0646347381400e80
2013-05-16 22:23:05 +00:00
'typeof': 'mw:Extension/ref'
Updates to cite to reflect spec for references and ref * Updated references output DOM to match spec better. * Also refactored some repetitive DOM code into helper functions. * Turned on tpl encapsulation inside extensions. * Verified output on the example in the spec and the example in commit 3c88b310. Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
2013-05-02 16:17:08 +00:00
});
Add capability for DOM-based template expansion, and use DOM fragments for extensions This patch adds the capability to expand individual transclusions all the way to DOM, which enforces properly nested templates. This is also needed for DOM-based template re-expansion, which the VE folks would like to use for template editing. In normal parsing, DOM-based expansion is currently disabled by default for transclusions, and enabled by default for extensions. The decision whether to balance a particular transclusion can be based on a statistics-based classification of templates into balanced and unbalanced ones. The advantage of this approach is consistency in behavior for old revisions. Another alternative is to wrap unbalanced transclusions into <domparse> tags which disable DOM-based parsing for all transclusions in its content. This has the advantage that all special cases can be handled after tag insertion, and that balancing could also be enforced in the PHP parser using an extension. Other major changes: * Renamed transclusion content typeof from mw:Object/Template to mw:Transclusion * Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo and switched Cite to use lower-case ref/references too Other minor changes: * Only apply template encapsulation algorithm on DOM to mw:Transclusion and mw:Param objects, and no longer to all mw:Object/* elements. We should probably switch to a more explicit encapsulation type instead. Maybe something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion instead of the current mw:Transclusion and mw:Transclusion/End, so that stripping those metas out selectively is easy? * Changed the DOMTraverser logic to let handlers explicitly return the next element to handle. Useful when several siblings are handled, as is the case for the fragment unwrapper for example, and avoids some cases where deleted nodes were still being processed. * Changed Cite to use mw:Extension/Ref{,erences} as all other extensions. * Make sure we round-trip gallery when the PHP preprocessor is not used Five parsoid-specific wt2html tests are failing due to the typeof change. They will be fine once those tests are adjusted. For now, adding them to parser tests blacklist. TODO: * Switch the Cite extension to the generic DOMFragment mechanism instead of marker tokens. Change-Id: I64b560a12695256915d2196d0646347381400e80
2013-05-16 22:23:05 +00:00
span.data = {
parsoid: {
src: node.data.parsoid.src,
dsr: node.data.parsoid.dsr
}
};
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
// refIndex-span
node.parentNode.insertBefore(span, node);
// refIndex-a
var refIndex = doc.createElement('a');
refIndex.setAttribute('href', '#' + ref.target);
refIndex.appendChild(doc.createTextNode(
'[' + ((group === '') ? '' : group + ' ') + ref.groupIndex + ']'
));
span.appendChild(refIndex);
}
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
// This effectively ignores content from later references with the same name.
// The implicit assumption is that that all those identically named refs. are
// of the form <ref name='foo' />
if (!ref.content) {
ref.content = node.getAttribute("content");
Forward-port Cite extension * Adapted Cite extension to use current interfaces and token formats * Improved TokenCollector Change-Id: I20419b19edd9bbad2c2abf17a2ff1411b99c0c04
2012-05-03 11:05:28 +00:00
}
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
};
References.prototype.insertReferencesIntoDOM = function(refsNode) {
var group = refsNode.getAttribute("group") || '',
(Bug 49182) Emit data-mw for references extension as well * data-mw wasn't being emitted for references -- there was a FIXME for it. * Tested fixes on example from 3c88b310. * Removed meta-placeholder that was being emitted for <references /> tags without any refs to emit since VE might add references and this wont be valid anymore. Serializer can also handle references output without any content. So, no need for that hack anymore. Verified by testing with "<references />" input Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
2013-06-05 16:06:10 +00:00
about = refsNode.getAttribute('about'),
Enable wrapped extensions to parse and RT correctly * Temporarily hacked sanitizer to pass through typeof attribute so that mw:DOMFragment wrapper for extension tags can get to the DOM post processor and get unwrapped. * Implemented getArgDict for the extension handler since data-mw for extensions has a different form than that for templates. * Extracted common functionality into Util.js and used it in Cite.js and ExtensionHandler.js * Tested with timeline extension (test snippet below) and verified that it parses and RTs both with editMode true and false. TODO: Long overdue. Extension testing. -------- <timeline> ImageSize = width:250 height:200 PlotArea = left:40 right:10 top:10 bottom:20 TimeAxis = orientation:horizontal AlignBars = justify Colors = id:gray1 value:gray(0.9) DateFormat = yyyy Period = from:1960 till:2010 ScaleMajor = unit:year increment:10 start:1960 PlotData = bar:3000 color:gray1 width:1 from:start till:end bar:2000 color:gray1 from:start till:end bar:1000 color:gray1 from:start till:end bar:0 color:gray1 LineData = layer:front points:(48,96)(84,111) color:blue width:2 #1962 tot 1968. Inwonertal 1962: 1348 1968: 1610 points:(84,111)(100,112) color:blue width:2 #1975: 1627 points:(100,112)(128,116) color:blue width:2 #1982: 1699 points:(128,116)(160,135) color:blue width:2 #1990: 2036 points:(160,135)(196,146) color:blue width:2 #1999: 2217 points:(196,146)(228,158) color:blue width:2 #2004/5 </timeline> -------- Change-Id: Ia8d2f82e893047e2447cf809e04cc7f508f5899b
2013-06-06 00:00:41 +00:00
src = refsNode.getAttribute('source'),
(Bug 49182) Emit data-mw for references extension as well * data-mw wasn't being emitted for references -- there was a FIXME for it. * Tested fixes on example from 3c88b310. * Removed meta-placeholder that was being emitted for <references /> tags without any refs to emit since VE might add references and this wont be valid anymore. Serializer can also handle references output without any content. So, no need for that hack anymore. Verified by testing with "<references />" input Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
2013-06-05 16:06:10 +00:00
// Extract ext-source for <references>..</references> usage
Enable wrapped extensions to parse and RT correctly * Temporarily hacked sanitizer to pass through typeof attribute so that mw:DOMFragment wrapper for extension tags can get to the DOM post processor and get unwrapped. * Implemented getArgDict for the extension handler since data-mw for extensions has a different form than that for templates. * Extracted common functionality into Util.js and used it in Cite.js and ExtensionHandler.js * Tested with timeline extension (test snippet below) and verified that it parses and RTs both with editMode true and false. TODO: Long overdue. Extension testing. -------- <timeline> ImageSize = width:250 height:200 PlotArea = left:40 right:10 top:10 bottom:20 TimeAxis = orientation:horizontal AlignBars = justify Colors = id:gray1 value:gray(0.9) DateFormat = yyyy Period = from:1960 till:2010 ScaleMajor = unit:year increment:10 start:1960 PlotData = bar:3000 color:gray1 width:1 from:start till:end bar:2000 color:gray1 from:start till:end bar:1000 color:gray1 from:start till:end bar:0 color:gray1 LineData = layer:front points:(48,96)(84,111) color:blue width:2 #1962 tot 1968. Inwonertal 1962: 1348 1968: 1610 points:(84,111)(100,112) color:blue width:2 #1975: 1627 points:(100,112)(128,116) color:blue width:2 #1982: 1699 points:(128,116)(160,135) color:blue width:2 #1990: 2036 points:(160,135)(196,146) color:blue width:2 #1999: 2217 points:(196,146)(228,158) color:blue width:2 #2004/5 </timeline> -------- Change-Id: Ia8d2f82e893047e2447cf809e04cc7f508f5899b
2013-06-06 00:00:41 +00:00
body = Util.extractExtBody("references", src).trim(),
(Bug 49182) Emit data-mw for references extension as well * data-mw wasn't being emitted for references -- there was a FIXME for it. * Tested fixes on example from 3c88b310. * Removed meta-placeholder that was being emitted for <references /> tags without any refs to emit since VE might add references and this wont be valid anymore. Serializer can also handle references output without any content. So, no need for that hack anymore. Verified by testing with "<references />" input Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
2013-06-05 16:06:10 +00:00
refGroup = this.refGroups[group],
ol = refsNode.ownerDocument.createElement('ol');
DU.addAttributes(ol, {
'about': about,
'class': 'references',
'data-mw': JSON.stringify({
'name': 'references',
(Bug 48808) Serialize edited extension content * Extensions were being serialized back to original wikitext src. * This patch now uses data-mw content to serialize to extension wikitext. * Fixed Cite to add attributes for ref to data-mw so that attributes roundtrip back (WS and quotes are normalized). * TODO: 1. add data-mw for <references> in Cite.js 2. add data-mw for all other extensions in the extension handler Change-Id: If3c35398a409f4775204407b3dcf2442ec2fb4e5
2013-05-25 14:38:13 +00:00
// We'll have to output data-mw.body.extsrc in
// scenarios where original wikitext was of the form:
// "<references> lot of refs here </references>"
// Ex: See [[en:Barack Obama]]
(Bug 49182) Emit data-mw for references extension as well * data-mw wasn't being emitted for references -- there was a FIXME for it. * Tested fixes on example from 3c88b310. * Removed meta-placeholder that was being emitted for <references /> tags without any refs to emit since VE might add references and this wont be valid anymore. Serializer can also handle references output without any content. So, no need for that hack anymore. Verified by testing with "<references />" input Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
2013-06-05 16:06:10 +00:00
'body': body.length > 0 ? { 'extsrc': body } : undefined,
'attrs': {
// Dont emit empty keys
'group': group || undefined
}
}),
'typeof': 'mw:Extension/references'
});
ol.data = refsNode.data;
if (refGroup) {
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
refGroup.refs.map(refGroup.renderLine.bind(refGroup, ol));
}
(Bug 49182) Emit data-mw for references extension as well * data-mw wasn't being emitted for references -- there was a FIXME for it. * Tested fixes on example from 3c88b310. * Removed meta-placeholder that was being emitted for <references /> tags without any refs to emit since VE might add references and this wont be valid anymore. Serializer can also handle references output without any content. So, no need for that hack anymore. Verified by testing with "<references />" input Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
2013-06-05 16:06:10 +00:00
refsNode.parentNode.replaceChild(ol, refsNode);
Extension handling rewrite + cite extension refactoring. Tokenization ------------ * Fixed tokenizer to correctly parse extension tags in different contexts: with start and end tags, in self-closing tag mode, and to correctly handle scenarios when the exension end-tag is followed by a '#' (the special char used to skip over extension content). * Removed the distinction in the tokenizer between installed extensions and natively supported extension tags (<ref> and <references> for ex.). They all tokenize and get processed identically and get handled by different paths in the extension handler. * Template and TemplateArg tokens now carry tpl. transclusion source alongwith them since tsr information will not be accurate when they show up in extension contexts that in turn showed up in template context that were expanded by the php preprocessor. Ex: {{echo|<ref>{{echo|foo}}</ref>}} The tsr for the ref-tag will correspond to the template-source of the echo-template, NOT the original top-level page. So, env.page.src.substring(..) will return incorrect source for the innermost {{echo|foo}}. This fix of carrying along tpl transclusion source in the token itself eliminates this problem. Knowledge of native extensions ------------------------------ * Natively implemented extension tags (<ref> and <references>) are hardcoded in env.conf.parsoid. At some point, it would be good to have a registration mechanism for parsoid-native extensions. Extension handling ------------------ * Extracted extension handling out of the template handler into its own handler class. Right now, this class inherits from the template handler in order to be able to reuse a lot of the expansion and encapsulation functionality currently in the Template Handler. * This handler now handles extensions that are: (a) natively implemented and registered with Parsoid. (b) implemented as a PHP extension and expanded by relying on the PHP preprocessor. For (a), it uses information from env.conf.parsoid to find ext-handlers for natively implemented ext-tags. However, this can be cleaned up at some point by making available a registration mechanism. Cite/Ref/References ------------------- * Reworked the cite handler to split up ref-token processing and references token processing. * The handler now processes ref-tokens, parses content all the way to html output and encapsulates the html in an attribute of a meta-token that serves as a placeholder for where the ref-token occured. * References are handled as a DOM post-pass where these meta placeholder tokens are collected, content extracted from the attribute and spit out at the site of a references tag. The DOM walking is in DOMPostProcessor.js, but the actual processing is part of the Cite.js to keep all cite extension handling code in one place. Parser pipeline --------------- * Restructured parser pipeline recipes based on changes to Cite, TemplateHandler, and ExtensionHandler. * Added a couple functions to the parser pipeline: 1. resetState to reset state before starting a new top-level parse when pipelines are reused across top-level parses (ex: parser tests) 2. setSourceOffsets to set start/end offsets of the source being handled by the pipeline. This is required to correctly set tsr values when extension content (which is a substring of original top-level text) is parsed in its own pipeline. Other fixes ----------- * Removed env parameter from the Params object since it was not being used and seemed like unnecessary state propagation. * Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code in the tokenizer that converts "\n" in text to NlTks. * Cleanup of Util.shiftTokenTSR. * ext.util.TokenCollection is now no longer used by anything. Added a FIXME and left around in case we are able to improve tokenizing and handling of *include* tags that can eliminate the need for the messy TokenAndAttrCollector. Test results ------------ * No change in parser tests results. * Tested with a few different files. - en:BO page seems to be parsed about 10% faster than before (needs verification). - Referencs on the en:BO page seem to be more accurate than before. Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
2013-03-09 00:07:59 +00:00
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
// reset
this.reset(group);
A collection of small bug fixes to the grammar, Cite, the Token format converter and the HTML DOM -> WikiDom converter. The tokenizer now digests all parserTests.
2011-12-14 23:38:46 +00:00
};
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
Fix a bunch of jshint warnings. Most of these warnings are globals defined in mediawiki.parser.defines.js, which we turn into proper local variables. But there are a grab page of other use-before-def, missing semicolon, bad line break, and other minor warnings. No tricky stuff attempted in this patch, this should be safe obvious fixes only... although there is a nasty circular dependency between Util and parser.defines which had to be broken. Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
2013-04-22 19:51:09 +00:00
/**
* Native Parsoid implementation of the Cite extension
* that ties together <ref> and <references>
*/
var Cite = function() {
this.ref = new Ref(this);
this.references = new References(this);
};
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
Cite.prototype.resetState = function(group) {
Fix a bunch of jshint warnings. Most of these warnings are globals defined in mediawiki.parser.defines.js, which we turn into proper local variables. But there are a grab page of other use-before-def, missing semicolon, bad line break, and other minor warnings. No tricky stuff attempted in this patch, this should be safe obvious fixes only... although there is a nasty circular dependency between Util and parser.defines which had to be broken. Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
2013-04-22 19:51:09 +00:00
this.ref.reset();
Moved ref-index generation to DOM post-pass * When I last fixed Cite in commit 0164b846, I didn't take it all the way through. I was assigning ref indexes in the async pipeline which is incorrect since ref-tokens and references-tokens should be processed in the same order as they show up in the input. * I now moved ref-index assignment to the DOM post processor phase where they always belonged. * Fixed references and cite reset functions to only reset a specific group, if necessary. * Pipelines processing template transclusions should propagate the extension tag if the transclusion showed up in the context of extension source so that any extension-specific constraints are respected. (Ex: ref-tags in reference-extension context are handled differently -- and this should continue to be true even when the tags show up via transcluded content) * These fixes were tested on the following snippet from 0164b846. Where this snippet was generating buggy output earlier, it is now being handled correctly. --------------------------- X1<ref name="x" /> X2<ref name="x" /> <references> <ref name="x">x</ref> </references> Y<ref name="y">{{echo|y}}</ref> Z<ref name="z" /> <references> {{echo|<ref name="z">z</ref>}} </references> A<ref name="a">a</ref> B<ref name="b" /> <references> {{echo|<ref name="b">b</ref>}} </references> C<ref name="c">c</ref> D<ref name="d" /> <references> <ref name="d">{{echo|d}}</ref> </references> --------------------------- X1<ref name="x" /> X2<ref name="x" /> Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
2013-04-24 19:09:08 +00:00
this.references.reset(group);
Fix a bunch of jshint warnings. Most of these warnings are globals defined in mediawiki.parser.defines.js, which we turn into proper local variables. But there are a grab page of other use-before-def, missing semicolon, bad line break, and other minor warnings. No tricky stuff attempted in this patch, this should be safe obvious fixes only... although there is a nasty circular dependency between Util and parser.defines which had to be broken. Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
2013-04-22 19:51:09 +00:00
};
Improved template roundtripping based on WT ranges on DOM nodes. - Fixed several bugs in the DSR computation. - Deleted comment tokens from template output. - Eliminated TSR info from template output. - Rearranged order of DOM post passes. - Updated template encapsulation to use DSR values. - There are still a few missing pieces and scenarios that are not handled properly. Change-Id: I644914902ec1d27418138b107abe765f81178398
2012-09-17 19:46:44 +00:00
if (typeof module === "object") {
Convert the Cite extension to a token stream transformer. This required a few further additions to the TokenTransformDispatcher. In particular, there is now an 'any' token match whose callbacks are executed before more specific callbacks. This is used by the Cite extension to eat all tokens between ref and /ref tags. This need is very common, so should be broken out to an intermediate layer in the future. In general, the requirements for the TokenTransformDispatcher API are now clearer, and the API should likely be cleaned up / simplified.
2011-12-13 14:48:47 +00:00
module.exports.Cite = Cite;
}
Reference in a new issue Copy permalink