On 1/5/07, Brion Vibber brion@pobox.com wrote:
"IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view.
The syntax lacks discoverability, which could be addressed by making it more verbose. Beyond that, I don't think the deficiencies of our general approach to extensions should be held against this particular one.
What could be a long term solution? Perhaps a combination of the following: a) a general namespace devoted to syntax that is passed to extensions, e.g., Render: b) a hook mechanism that makes it possible to define a frontend for creating or updating data of a particular type (extension tag).
When following a red link to e.g. [[Render:Timeline US history]], one would be taken to a selection box to choose the extension which should be used for rendering. If a frontend is defined for that extension, one could use it to create (and later edit) the timeline. But when editing such a page, one could also switch to "Edit source" mode to modify the extension code directly, and that would be the only mode available if no front-end is given.
In such a model, tables could be turned into an extension. Their frequent interaction with templates would complicate things, however.