brion@svn.wikimedia.org schreef:
Revision: 37009 Author: brion Date: 2008-07-03 21:25:20 +0000 (Thu, 03 Jul 2008)
Log Message:
Have been playing with custom API modules and been a bit frustrated with the XML output mode... Adding pseudo-element _attribs alongside _element for XML output. There doesn't seem to be a good way currently to specify both attributes *and* subelements
That works just perfectly with stuff like array('foo' => 'bar', array('*' => 'stuff')) which will translate to <tag foo="bar"> <tag>stuff</tag> </tag>
I really don't see the point in this commit, and I'd rather see it reverted.
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roan Kattouw wrote:
brion@svn.wikimedia.org schreef:
Have been playing with custom API modules and been a bit frustrated with the XML output mode... Adding pseudo-element _attribs alongside _element for XML output. There doesn't seem to be a good way currently to specify both attributes *and* subelements
That works just perfectly with stuff like array('foo' => 'bar', array('*' => 'stuff')) which will translate to
<tag foo="bar"> <tag>stuff</tag> </tag>
I really don't see the point in this commit, and I'd rather see it reverted.
The basic problem seems to be overloading of attributes and sub-elements in the same array, which means you can't have both very consistently. It makes it hard to use it as a general-purpose XML output system.
If I could do this:
array( 'attrib1' => 'val1', 'attrib2' => 'val2', '*' => array( 'tag' => 'stuff' 'tag2' => 'stuff2', ) )
then that might do the job, but it doesn't seem to happy with that currently:
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /Library/WebServer/Documents/trunk/includes/Xml.php on line 31
- -- brion
Brion Vibber schreef:
The basic problem seems to be overloading of attributes and sub-elements in the same array, which means you can't have both very consistently. It makes it hard to use it as a general-purpose XML output system.
If I could do this:
array( 'attrib1' => 'val1', 'attrib2' => 'val2', '*' => array( 'tag' => 'stuff' 'tag2' => 'stuff2', ) )
then that might do the job, but it doesn't seem to happy with that currently:
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /Library/WebServer/Documents/trunk/includes/Xml.php on line 31
Of course that gives a warning, since the '*' element is supposed to contain text. IIRC, the following should work:
array( 'attrib1' => 'val1', 'attrib2' => 'val2', array( 'tag' => 'stuff', 'tag2' => 'stuff2', ) )
If it doesn't, we should correct the formatter so that it does. Introducing _attribs is also not a very good idea considering how that looks in other formats.
Roan Kattouw (Catrope)
Roan Kattouw wrote: [snippy]
Of course that gives a warning, since the '*' element is supposed to contain text. IIRC, the following should work:
array( 'attrib1' => 'val1', 'attrib2' => 'val2', array( 'tag' => 'stuff', 'tag2' => 'stuff2', ) )
Ahh, that seems to do it! Thanks... reverted in r37075.
If it doesn't, we should correct the formatter so that it does. Introducing _attribs is also not a very good idea considering how that looks in other formats.
No different to _element...
-- brion
Brion Vibber schreef:
No different to _element...
Actually, they *are* different. _element doesn't contain any real information. It's there to facilitate displaying arrays with numerical indices in XML (tag names obviously can't be numerical, so we choose a tag name that makes sense in context but doesn't say anything new, such as <page> or <rev> as children of the <pages> or <revisions> element respectively). _element is never set directly, the code uses ApiResult::setIndexedTagName() which checks which formatter we're using, and does nothing if we're not using an XML formatter. For this reason, the non-XML formatters never get to see these _element elements, which is no problem because those formats do have a native way to represent arrays with numerical indices and therefore don't need the _element workaround.
_attribs was different in that it actually *did* contain information, which would also have to be passed to other formatters. However, those formatters would then have to convert _attribs back to something that makes sense from a non-XML point of view, or you'd have to do some formatter-specific stuff in ApiResult::addValue()
Roan Kattouw (Catrope)
Roan Kattouw wrote:
_attribs was different in that it actually *did* contain information, which would also have to be passed to other formatters.
Like _element, it wouldn't have been ever given to other formatters.
But this is moot, since you showed me the secret recipe for doing this without it. :D
-- brion
wikitech-l@lists.wikimedia.org