On 13.05.2013 21:26, Max Semenik wrote:
Hi, I've seen recently a lot of code like this:
$html = Html::openElement( 'div', array( 'class' => 'foo' ) . Html::rawElement( 'p', array(), Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ), $somePotentiallyUnsafeText ) ) . Html::closeElement( 'div' );
IMO, cruft like this makes things harder to read and adds additional performance overhead. It can be simplified to
$html = '<div class="foo'><p>' . Html::rawElement( 'p', array(), Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ), $somePotentiallyUnsafeText ) ) . '</p></div>';
What's your opinion, guys and gals?
In my Extension:QPoll I implemented tag arrays, which are more compact and support auto-closing of tags (no closeElement() is needed): http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/QPoll/includes/qp...
For performance reasons I did not bother about attribute validation and inner text quotation, performing these tasks in caller instead. Output generarion was simple recursive traversal of nested PHP arrays.
However, it also has methods to "dynamically" add columns and rows to html tables, including colspans and rowspans.
The class worked well enough allowing to manipulate content, however subtree inserting and moving was not so elegant.
When I forced to abandon MediaWiki development due to financial reasons, I re-thinked the class and made the same tagarrays based on XMLDocument and XMLWriter:
https://bitbucket.org/sdvpartnership/questpc-framework/src/a5482dd1035b6393f... https://bitbucket.org/sdvpartnership/questpc-framework/src/a5482dd1035b6393f...
They are slower than "echo $var;" for sure, but allow much more powerful tag manipulation and templating in jQuery-like way. And the output is always valid and of course XMLDocument automatically cares about inner text escaping and so on.
Here's an example of newer version of tag array definition: array( '@tag' => 'div', 'class' => 'foo', array( '@tag' => 'p', array( '@tag' => 'span', 'id' => $id, $text ) ) );
String keys starting from '@' are special keys: '@tag' is a tag name, '@len' (optional) is count of child nodes. Another string keys are attribute key / value pairs. Integer keys are nested nodes - either nested tags or text nodes. Also there are three special tag names: '@tag' => '#text' '@tag' => '#comment' '@tag'=>'#cdata'
Dmitriy