On 01/13/2013 07:00 PM, wikitech-l-requ...@lists.wikimedia.org wrote:
From: Daniel Kinzler<dan...@brightbyte.de>
To: Wikimedia developers<wikitech-l@lists.wikimedia.org>
Subject: Re: [Wikitech-l] Release Notes and ContentHandler
Message-ID:<50f2abf9.4020...@brightbyte.de>
Content-Type: text/plain; charset=ISO-8859-1
On 13.01.2013 02:02, Lee Worden wrote:
>Yes, I think ContentHandler does some of what WW does, and I'll be happy to
>integrate with it. I don't think we'll want to abandon the source-file tag,
>though, because on pages like
>http://lalashan.mcmaster.ca/theobio/math/index.php/Nomogram and
>http://lalashan.mcmaster.ca/theobio/worden/index.php/Selection_Gradients/MacLev,
>it's good to be able to intertwine source code with the rest of the page's
>wikitext.
ContentHandler does not yet have good support for inclusion - currently, there's
just Content::getWikitextForInclusion(), which is annoying. It would be much
nicer if we had Content::getHTMLForInclusion(). That would allow us to
transclude any kind of content anywhere.
That would mean taht instead of <source-file>Foo.tex</source-file>, you could
just use {{:Foo.tex}} to transclude Foo.tex's content. Actually, you could
implement getWikitextForInclusion() to return
<source-file>Foo.tex</source-file>, I guess - but that's cheating ;)
It's not <source-file>Foo.tex</source-file> - that would be ridiculous.
If nothing else, I'd use <source-file filename="Foo.tex"/>. :) [In
fact, I do support that form, but it's hardly ever used.]
No, it's <source-file filename="Foo.tex">\documentclass{article} [...]
\end{document}</source-file>. It stores the actual source code. The
file is not transcluded. This may seem ridiculous at first blush, and
you might never want to do that with long .tex files or Python modules,
but think instead of explaining a concept by using a series of little
4-line programs, to illustrate each step. You can think of
<source-file> as <syntaxhighlight> with semantics behind it. It
displays a code listing, with highlighting, but it also lets you run the
code, in context, and display the output.
There are plenty of use cases where you don't want to do that, you just
want to put each source file on its own page, and I support that now,
and I'll definitely support the use of ContentHandler when it's time, as
I've been planning to all along. But the ability to edit, run, test,
and refine the code by pressing the Preview button, without saving your
changes to the wiki until you're satisfied, even if the code is in
multiple source files, is a valuable affordance, and we may not want to
give it up.
>Also, in a multi-file project, for instance a simple LaTeX project with a .tex
>file and a .bib file, it's useful to put the files on a single page so you can
>edit and preview them for a while before saving.
That would not change when using the ContentHandler: You would have one page for
the .tex file, one for the .bib file, etc. The difference is that MediaWiki will
know about the different types of content, so it can provide different rendering
methods (syntax highlighted source or html output, as you like), different
editing methods (input forms for bibtext entries?).
>
Basically, you no longer need nasty hacks to work around MediaWiki's assumption
that pages contain wikitext, because that assumption was removed in 1.21.
Bundling several source files onto a single page, with wikitext
interspersed, is a form of literate programming. It's part of the same
tradition as knitr, R markdown, sage notebooks, etc. There are valuable
uses for embedding code in free-form markup, and I think it's useful to
be able to do it in MediaWiki.
LW
-- daniel
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
