On Tue, Sep 16, 2014 at 10:40 PM, Jackmcbarn <jackmcbarn(a)gmail.com> wrote:
1. [[File:Module:Foo|bar=baz|width=200px]] -
Module:Foo gets called to
generate the file
3. [[File:Any file that doesn't exist.svg|bar=baz|width=200px]] -
Module:FileHandlers/Any file that doesn't exist.svg gets called to
generate the file
I like either of these. I don't see any files on enwiki[1] or Commons[2]
with names beginning "Module:", so I doubt collisions are much of a concern.
IMO, the disadvantages for option 4 (not being usable for anything that
wants filenames rather than the full image link syntax) outweigh the
advantage of the similar syntax.
I note that neither of the syntax examples given allows you to specify
which method in the module to invoke. I don't think we should try to
provide one, we should just define that it always invokes "renderFile"
(feel free to bikeshed the name).
We should be able to use the same code path on the image page that is used
for Commons images, although the default text of the relevant messages
might need work. If we go that route, we should also define that
"extraDescription" returns wikitext to include in the image page (like how
the description page from Commons is shown).
We should probably also require that a file extension be included on the
module name, and use the existing code that's used on upload to validate
that the file content matches the extension.
As for image syntax parameter handling, the current flow for parsing the
syntax seems to be something along these lines:
* A 'File' object is fetched for the named image.
* The file's media handler is asked for a list of parameters it recognizes,
which can even override a core parameter.
* Each pipe-separated parameter gets checked for matching one of these
magic words. Handler-specified parameters get passed to a callback on the
handler, although if it's named 'width' it gets special pre-parsing.
* If the parameter is valid, it gets collected in an assoc (grouped by
type, e.g. 'frame' or 'handler'); otherwise it's used as the caption.
* Eventually, the file gets asked to generate a thumbnail object (and gets
passed all the "handler" parameters from above). And then the thumbnail
object gets asked to generate the HTML.
We'd probably have to add a new media handler method called to preprocess
each option so we can collect them to pass to Lua later.
One other issue to consider is how the rendered files will be cached and
purged, especially considering that people almost certainly will do stuff
like have [[File:GraphMyData.svg]] use mw.title:getContent() to load data
off of a wiki page of some sort and we'd ideally like to purge the rendered
file when that wiki page gets changed.
[1]:
https://en.wikipedia.org/w/api.php?action=query&list=allimages|allpages…
:
[2]:
https://commons.wikimedia.org/w/api.php?action=query&list=allimages|all…
:
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation