wiki.techinc.nl/includes/content/JsonContent.php

202 lines
4.6 KiB
PHP
Raw Normal View History

<?php
/**
* JSON Content Model
*
* @file
*
* @author Ori Livneh <ori@wikimedia.org>
* @author Kunal Mehta <legoktm@gmail.com>
*/
/**
* Represents the content of a JSON content.
* @since 1.24
*/
class JsonContent extends TextContent {
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
/**
* @since 1.25
* @var Status
*/
protected $jsonParse;
/**
* @param string $text JSON
* @param string $modelId
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
*/
public function __construct( $text, $modelId = CONTENT_MODEL_JSON ) {
parent::__construct( $text, $modelId );
}
/**
* Decodes the JSON string.
*
* Note that this parses it without casting objects to associative arrays.
* Objects and arrays are kept as distinguishable types in the PHP values.
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
*
* @return Status
*/
public function getData() {
if ( $this->jsonParse === null ) {
$this->jsonParse = FormatJson::parse( $this->getText() );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
return $this->jsonParse;
}
/**
* @return bool Whether content is valid.
*/
public function isValid() {
return $this->getData()->isGood();
}
/**
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
* Pretty-print JSON.
*
* If called before validation, it may return JSON "null".
*
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
* @return string
*/
public function beautifyJSON() {
return FormatJson::encode( $this->getData()->getValue(), true, FormatJson::UTF8_OK );
}
/**
* Construct HTML table representation of any JSON value.
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
*
* See also valueCell, which is similar.
*
* @param mixed $val
* @return string HTML.
*/
public function rootValueTable( $val ) {
if ( is_object( $val ) ) {
return $this->objectTable( $val );
}
if ( is_array( $val ) ) {
// Wrap arrays in another array so that they're visually boxed in a container.
// Otherwise they are visually indistinguishable from a single value.
return $this->arrayTable( [ $val ] );
}
return Html::rawElement( 'table', [ 'class' => 'mw-json mw-json-single-value' ],
Html::rawElement( 'tbody', [],
Html::rawElement( 'tr', [],
Html::element( 'td', [], $this->primitiveValue( $val ) )
)
)
);
}
/**
* Create HTML table representing a JSON object.
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
*
* @param stdClass $mapping
* @return string HTML
*/
protected function objectTable( $mapping ) {
$rows = [];
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
$empty = true;
foreach ( $mapping as $key => $val ) {
$rows[] = $this->objectRow( $key, $val );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
$empty = false;
}
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
if ( $empty ) {
$rows[] = Html::rawElement( 'tr', [],
Html::element( 'td', [ 'class' => 'mw-json-empty' ],
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
wfMessage( 'content-json-empty-object' )->text()
)
);
}
return Html::rawElement( 'table', [ 'class' => 'mw-json' ],
Html::rawElement( 'tbody', [], implode( '', $rows ) )
);
}
/**
* Create HTML table row representing one object property.
*
* @param string $key
* @param mixed $val
* @return string HTML.
*/
protected function objectRow( $key, $val ) {
$thContent = Html::element( 'span', [], $key );
$th = Html::rawElement( 'th', [], $thContent );
$td = $this->valueCell( $val );
return Html::rawElement( 'tr', [], $th . $td );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
/**
* Create HTML table representing a JSON array.
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
*
* @param array $mapping
* @return string HTML
*/
protected function arrayTable( $mapping ) {
$rows = [];
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
$empty = true;
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
foreach ( $mapping as $val ) {
$rows[] = $this->arrayRow( $val );
$empty = false;
}
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
if ( $empty ) {
$rows[] = Html::rawElement( 'tr', [],
Html::element( 'td', [ 'class' => 'mw-json-empty' ],
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
wfMessage( 'content-json-empty-array' )->text()
)
);
}
return Html::rawElement( 'table', [ 'class' => 'mw-json' ],
Html::rawElement( 'tbody', [], implode( "\n", $rows ) )
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
);
}
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
/**
* Create HTML table row representing the value in an array.
*
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
* @param mixed $val
* @return string HTML.
*/
protected function arrayRow( $val ) {
$td = $this->valueCell( $val );
return Html::rawElement( 'tr', [], $td );
}
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
/**
* Construct HTML table cell representing any JSON value.
*
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
* @param mixed $val
* @return string HTML.
*/
protected function valueCell( $val ) {
if ( is_object( $val ) ) {
return Html::rawElement( 'td', [], $this->objectTable( $val ) );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
if ( is_array( $val ) ) {
return Html::rawElement( 'td', [], $this->arrayTable( $val ) );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
return Html::element( 'td', [ 'class' => 'mw-json-value' ], $this->primitiveValue( $val ) );
}
/**
* Construct text representing a JSON primitive value.
*
* @param mixed $val
* @return string Text.
*/
protected function primitiveValue( $val ) {
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
if ( is_string( $val ) ) {
// Don't FormatJson::encode for strings since we want quotes
// and new lines to render visually instead of escaped.
return '"' . $val . '"';
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
return FormatJson::encode( $val );
content: Refactor and fix various bugs in JsonContent Follows-up d2a82fcb60. These issues weren't previously exposed as nothing uses JsonContent by default in core, and the extensions using it (e.g. EventLogging) lock it down very early. As are most of these methods were never really put to use (they were called after the extension does its superset of checking, or too early and WikiPage ignores it). Bug fixes * Empty JSON object was converted to an array by PST conversion. The beautifyJSON method is intended for prettify purposes but actually modified the content stored in the database and made it no longer roundtrip ({} != []). We can't change getJsonData to return an object since it's a public method and people use it as an array. So we can't cast it to a PHP object as that would break back-compat. Turns out the class doesn't even support non-objects anyway (a primitive in JSON can trivially cause a fatal as it wasn't consistently considered invalid, though it didn't actually fatal due to some lucky spaghetti code in WikiPage). * Fix beautifyJSON by checking for empty objects to prevent implicit {} to [] conversion. * Add isValid() check to fillParserOutput() as it's called early on. Otherwise it throws a warning that 'foreach' (in objectTable) iterates over null. In practice it doesn't matter since the entire parser output is rejected when WikiPage eventually checks isValid (through Content::prepareSave). * Consider all non- (PHP) array values invalid instead of just non-null values. Enhancements * Display message "Empty object" instead of a completely blank page for an empty object. * Display message "Empty object" or "Empty array" instead of an empty table cell. * Render arrays as a list of values (without indices). * Remove italics from table cells for values. The monospace font should be enough. It also offsets it from the "Empty" placeholders (which are italicised). Refactoring and clean up * Use FormatJson::parse so that we can use Status to distinguish between null parse result and thus reliably cache it. Ideally we wouldn't need to cache it, but right now this code is pulled apart and called in so many strange ways that we end up calling this several times. * Improve fairly meaningless test (testBeautifyJson) that was calling FormatJson in its data provider, exactly what the method being tested did. It also provided the test with data that could never end up in normal usage (a PHP-style associated array with implied numerical indices). * Document that this class rejects non-array values. * Document the problem with WikiPage assumming PST can run on any content. WikiPage fundamentally still assumes wikitext, in that there's no concept of invalid content. * Fix incorrect documentation for getJsonData's return value (It may return null.) * Fix incorrect documentation for beautifyJSON's return value. (It never returned boolean.) Bug: T76553 Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
2014-12-03 02:10:50 +00:00
}
}